The issue with the numbering is that the releases happen in parallel.
By the time we release a stable, we are usually ahead of the stable release in terms of development and features.
What we decided on was that we use a semantic versioning scheme. To avoid really odd numbering, the canary builds are starting at x.x.x.100 and growing from there.
This ensures that higher number means newer version. But “newer” is not related to date, it is related to the codebase. Due to our staged release method, a stable release is usually several weeks older than the “newest” codebase.
For the channel names, this is described here:
The “canary” name is a bit non-standard, but using the common “nightly” moniker suggests that a new build is ready every night, and we are not currently building fast enough to have a new version every day.
Yes, each release has a changelog. The release process is currently:
- Branch off, take the current canary (or close to it) and make an experimental, say v2.0.0.0
- Once tested (and no issues are blocking), make beta v2.0.0.1
- Once tested (and no issues are blocking), make stable v2.0.0.2
- If patches are needed, make beta v2.0.0.3
- Once tested (and no issues are blocking), make stable v2.0.0.4
This ensures that almost all code in a stable release has been available for public testing for a good while, reducing the chance that there are unknown issues.
If you are running 2.0.0.3 and want to figure out what has changed from 2.0.0.2 to 2.0.0.3, simply look at the changelog for 2.0.0.3.