Changes between Version 4 and Version 5 of BranchingPolicy
- Timestamp:
- 08/26/10 14:39:39 (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BranchingPolicy
v4 v5 2 2 3 3 CKAN is stored in a mercurial repo and we have devised this policy to cope with coding, releasing and maintaining versions of the software. 4 5 This policy reflects Python development ( http://www.python.org/dev/peps/pep-0374/#backport ), but instead of naming branches after their version numbers, they are named after the stability of the release. This allows `metastable` to always to be a beta, `stable` to be the latest solid release and `ultrastable` to be the previous-but-one release. 6 7 == Branches == 4 8 5 9 We have a number of maintained branches of the code to reflect their uses: … … 12 16 13 17 '''ultrastable''' branch is for the most stable code - proper releases, always one behind `stable`. 18 19 == Merging between the branches == 14 20 15 21 This arrangement can be seen to be like a waterfall of changesets. `default` has the most, `metastable` is a subset of `default`, `stable` a subset of `metastable` etc. As the releases go down the waterfall, the bug-fixes go in the opposite direction: