Changes between Initial Version and Version 1 of BranchingPolicy

08/26/10 10:56:31 (4 years ago)



  • BranchingPolicy

    v1 v1  
     1CKAN is stored in a mercurial repo and we have devised this policy to cope with coding, releasing and maintaining versions of the software. 
     3We have a number of maintained branches of the code to reflect their uses: 
     5'''default''' branch is for future releases - New features go here. Bug fixes should always go here as well as the other branches. 
     7'''metastable''' branch is for releases deployed to and similar servers. These servers get new features first. Sometimes there are issues to be resolved with these new features. It usually lags `default`. 
     9'''stable''' branch is for very stable code - major releases. It usually lags `metastable`. 
     11'''ultrastable''' branch is for the most stable code - major releases, one behind `stable`. 
     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. 
     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. 
     17You might have written a bugfix in `default` that you want in `metastable` too, but don't want the rigmorole of releasing all the code in `default` at this point. In this case, don't merge - the problem with merging, is that you may well pull half-finished features from `default`. 
     19The solution (instead of `hg merge`) is to `hg export` particular changesets from one branch and `hg import` it to another. 
     21== 'tip' note == 
     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.