Rooba
/
flatbuffers
mirror of https://github.com/google/flatbuffers.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Removed part on git hash and just went with a release number. Fixed spelling errors.

Derek Bailey 2022-11-30 19:13:58 -08:00
parent 07a7411733
commit a88b18b189
1 changed files with 9 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
Versioning.md

@ -8,7 +8,7 @@ version numbers. Due to our Continuous Integration process, any of our commits
are valid versions to work off and have been tested as a whole together.
But we also realize that others rely on package managers for their languages for
integration into their projects. So we too ocassionally cut releases and upload
integration into their projects. So we too occasionally cut releases and upload
a snapshot to various package managers.
## Releases
@ -19,7 +19,7 @@ map or schedule that is followed.
## Versioning Scheme
FlatBuffers has a version in the format: `YY.MM.DD[-GITHASH]`
FlatBuffers has a version in the format: `YY.MM.DD`
Where `YY` is the current year minus 2000 (e.g., `2023` is `23`).
@ -27,19 +27,13 @@ The `MM` is the month from Jan (`1`) to Dec (`12`).
And `DD` is the day of the month, from `1` to `31`.
Since it is possible for multiple releases to happen on the same date an
optional git hash may be present.
An example version would be:
The `GITHASH` is the 7-digit prefix of the git commit hash of the **previous**
commit to the annotated tag that marks a release. This allows one to easily find
the commit (e.g. https://github.com/google/flatbuffers/commit/bc44fad)
`22.09.14`
An Example version would be:
In case of two or more releases on a given day, the format may be appended with a further `.{release #}` (e.g. `22.09.14.2` would be the second release). _This isn't intended to occur often._
`22.09.14-bc44fad`
This format has the folloing nice properties:
This format has the following nice properties:
1. Its has lexicographic ordering, so easy to tell what is newer.
1. It's a date, so it is easy to know when in time it was released.
@ -48,10 +42,10 @@ This format has the folloing nice properties:
### Not Semantic Versioning
This is very smilar format to [Semantic Versioning](https://semver.org/), but we
This is very similar format to [Semantic Versioning](https://semver.org/), but we
don't prescribe to hold to semantic versioning. Why Not?
Since flatbuffers involves multiple pieces working in tandem:
Since FlatBuffers involves multiple pieces working in tandem:
1. The `flatc` compiler that parses schema and write codes gen
2. The individual language "run time" libraries
@ -66,7 +60,7 @@ As an example, consider using a single version at `1.2.3`. Suppose Jane spotted
a bug in the Java runtime library which needs to be fixed and it is breaking
change. She could fix the bug and bump up the "major" version to `2.0.0` and
release. This would cause all the other languages to be updated to `2.0.0`.
Peter the `python` developer notices that the major version of flatbuffers
Peter the `python` developer notices that the major version of FlatBuffers
changed, and may A) hesitate to update because he thinks there are breaking
changes, or B) updates but doesn't see anything different with the python
libraries and wonder why he spent time updating. Either choice causes unneeded