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