From a88b18b189f52d88bb9919a90343d89c4e1ed9fb Mon Sep 17 00:00:00 2001 From: Derek Bailey Date: Wed, 30 Nov 2022 19:13:58 -0800 Subject: [PATCH] Removed part on git hash and just went with a release number. Fixed spelling errors. --- Versioning.md | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/Versioning.md b/Versioning.md index 2517c4a..f4b7b3e 100644 --- a/Versioning.md +++ b/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