| | 1 | We generally have a major and minor version number. e.g. `1.5` Sometimes we have point releases, e.g. `1.5.1`. Note: These are not 'decimal' numbers, simply integers separated by a dot. e.g. `1.11` is 'one point eleven', not 'one point one one' and is a later release than `1.2`. |
| | 2 | |
| | 3 | On the `default` branch, when you approach a release, we up the minor version number, and add `a` to indicate alpha, e.g. `1.2a`. There may be further trial states e.g. `1.2b` and `1.2c`, before the final release of `1.2`. |
| | 4 | |
| | 5 | The final release goes to the metastable and eventually the other branches too, keeping this version number. |
| | 6 | |
| | 7 | Note, changes go into the `default` branch, but the version number stays the same. |
| | 8 | |
| | 9 | Bugfixes may appear on branches, yet by default, the code will also keep the same version number. That is unless we decided that the fix is useful to advertise, and therefore released as a point release. Then the version number on `default` is upped (e.g. to `1.2.1`), and the same change made on other branches that have the fix. ''Note'', because `default` may have other changesets since the release unrelated to the fix, we ''can't merge'' from `default` to the branches for either the bugfix or the version number change - instead use `hg import` and `hg export`. |
