| | 1 | CKAN is stored in a mercurial repo and we have devised this policy to cope with coding, releasing and maintaining versions of the software. |
| | 2 | |
| | 3 | We have a number of maintained branches of the code to reflect their uses: |
| | 4 | |
| | 5 | '''default''' branch is for future releases - New features go here. Bug fixes should always go here as well as the other branches. |
| | 6 | |
| | 7 | '''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`. |
| | 8 | |
| | 9 | '''stable''' branch is for very stable code - major releases. It usually lags `metastable`. |
| | 10 | |
| | 11 | '''ultrastable''' branch is for the most stable code - major releases, one behind `stable`. |
| | 12 | |
| | 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 | |
| | 15 | The 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. |
| | 16 | |
| | 17 | You 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`. |
| | 18 | |
| | 19 | The solution (instead of `hg merge`) is to `hg export` particular changesets from one branch and `hg import` it to another. |
| | 20 | |
| | 21 | == 'tip' note == |
| | 22 | |
| | 23 | Mercurial 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. |
