Changes between Version 4 and Version 5 of BranchingPolicy


Ignore:
Timestamp:
08/26/10 14:39:39 (4 years ago)
Author:
dread
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BranchingPolicy

    v4 v5  
    22 
    33CKAN is stored in a mercurial repo and we have devised this policy to cope with coding, releasing and maintaining versions of the software. 
     4 
     5This 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 == 
    48 
    59We have a number of maintained branches of the code to reflect their uses: 
     
    1216 
    1317'''ultrastable''' branch is for the most stable code - proper releases, always one behind `stable`. 
     18 
     19== Merging between the branches == 
    1420 
    1521This 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: