Changes between Version 3 and Version 4 of VersionsAndBranching


Ignore:
Timestamp:
08/26/10 10:41:56 (4 years ago)
Author:
dread
Comment:

Info about ultrastable and version numbering

Legend:

Unmodified
Added
Removed
Modified
  • VersionsAndBranching

    v3 v4  
    11CKAN is stored in a mercurial repo and we have devised this process to cope with coding, releasing and maintaining versions of the software. 
    22 
    3 We have three branches of the code to reflect their uses: 
     3We have a number of maintained branches of the code to reflect their uses: 
    44 
    55'''default''' branch is for future releases - New features go here. Bug fixes should always go here as well as the other branches. 
     
    77'''metastable''' branch is for releases deployed to ckan.net and similar servers. These servers get new features first. Sometimes there are issues to be resolved with these new features. It usually lags `default`. 
    88 
    9 '''stable''' branch is designed for the most stable code. It usually lags `metastable`. 
     9'''stable''' branch is for very stable code - major releases. It usually lags `metastable`. 
    1010 
    11 (From now on) merges must only be done in the DOWN direction (in the direction `default`->`metastable`->`stable`) and only when you release. So you can release `default` to `metastable` with a merge, and from `metastable` to `stable`, but you mustn't merge `metastable` to `default`, for example. And not when you simply fix a bug. 
     11'''ultrastable''' branch is for the most stable code - major releases, one behind `stable`. 
    1212 
    13 The problem with merging in the other direction is that a bugfix changesets on `metastable` may well be mixed in with changesets incrementing the minor digit of the version number. The version number on the `default` branch may already have a higher major version and you don't want to overwrite it with the `metastable` changeset. When you merge you can't pick and choose changesets - you have all up to a certain one - so you can't merge in this direction. 
     13(From now on) merges must only be done in the DOWN direction (in the direction `default`->`metastable`->`stable`->`ultrastable`) and only when you release. This means that you would release `default` to `metastable` with a merge, and from `metastable` to `stable`, but you must not merge `metastable` to `default`, for example. And not when you simply fix a bug. 
     14 
     15The problem with merging in the other direction is that bugfix changesets on `metastable` may well be mixed in with changesets incrementing the minor digit of the version number. The version number on the `default` branch may already have a higher major version and you don't want to overwrite it with the `metastable` changeset. When you merge you can't pick and choose changesets - you have all up to a certain one - so you can't merge in this direction. 
    1416 
    1517You might have written a bugfix in `default` that you want in `metastable` too, but don't want the rigmorole of releasing at this point. In this case, don't merge - the problem with merging when you're not releasing, is that you may well pull half-finished features from `default` into branches which need to be more stable. 
    1618 
    17 The solution (instead of 'hg merge') is to 'hg export' particular changesets from one branch and 'hg import' it to another. 
     19The solution (instead of `hg merge`) is to `hg export` particular changesets from one branch and `hg import` it to another. 
    1820 
    19 == Notes == 
     21== 'tip' note == 
    2022 
    21 '''tip''' is what Mercurial tags the latest commit. So it changes on every commit and might be on any branch. So it's best not to refer to it in documentation, emails or changeset comments. 
     23Mercurial tags the latest commit with the tag `tip`. This means it changes on every commit and might be on ''any'' branch. So it's best not to refer to it in documentation, emails or changeset comments. 
     24 
     25== Version numbers == 
     26 
     27We generally have a major and minor version number. e.g. 1.5 It is not decimal, so 1.11 is 'one point eleven', not 'one point one one'. 
     28 
     29On 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`. 
     30 
     31The final release goes to the metastable and eventually the other branches too, keeping this version number. 
     32 
     33Bugfixes may appear on branches, yet by default, the code will keep the same version number. If the fix is warranted enough to be released as a point release, then the version number on `default` is upped (e.g. to 1.2.1), and the 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 - use `hg import` and `hg export`.