We are using so-called calendar versioning in the format
YYstands for the current year.
MMstands for the current month.
PATCHis increased on every release in the given month.
20.10.1first release in Oct 2020
20.10.3third release in Oct 2020
19.12.1first release in Dec 2019
We version beta in a similar way as production versions but we always set
PATCH to 0 and increase the
That means that every release on beta has 0 as the patch version. This has a drawback that you can't distinguish beta deployments by a version number, but beta testers should be able to read and report the commit hash.
Only stable releases have patch version >1 and this increases with each stable release: 1, 2, 3, 4.
Beta also has +1
MM version when compared to stable indicating this is upcoming release which will be deployed on stable next month.
20.10.1first release on Oct 15th to stable
20.10.2second release on Oct 22nd to stable
20.11.0release on Oct 29th 2020 to beta
20.11.0another release on Nov 5th to beta
20.11.1public release on Nov 14th to stable
We use the same scheme as beta. That is,
develop branch has always
YY.MM.0 version where
MM is the upcoming month's release.
When we fork
release/20YY-MM branch, we bump the release branch version to
develop version to
YY.(MM+1).0 indicating we are already brewing next release in the
Do not use
release-it to semi-automate the version bumping. It is very aggressive and it may delete/modify some Github releases.
Versions you need to modify manually for now besides all the package.json files: