CKAN: Ticket #1006: Deprecate stable branch

dread — Fri, 25 Feb 2011 10:52:25 GMT

This command is slightly different to your branch policy as of two weeks ago:

stable: stable code
metastable: (will soon be deprecated) for code preparing to be stable
default: development HEAD

which I prefer.

My ideal would be to get rid of the confusing name 'metastable' and unneeded 'stable' and start a new branch called 'released', which will act the same as 'master' in this diagram but with a more intuitive name: http://nvie.com/posts/a-successful-git-branching-model

Then for each ckan instance we can either use the most recent release (from 'released') or choose a specific one (e.g. 'ckan-1.3' or even 'default' or 'enh-865' for getting latest features). This gives a good degree of flexibility, is more understandable to newbies and probably a more widely understood branching model.

milestone changed

dread — Mon, 28 Feb 2011 10:12:12 GMT

milestone changed from ckan-v1.4-sprint-2 to ckan-v1.4-sprint-3

owner, milestone changed

dread — Mon, 14 Mar 2011 10:23:37 GMT

owner changed from dread to rgrp
milestone changed from ckan-v1.4-sprint-3 to ckan-v1.4-sprint-4

Reassigning to rgrp for response

owner changed

rgrp — Mon, 14 Mar 2011 12:32:07 GMT

owner changed from rgrp to kindly

Not sure when i described that other process but I'm definitely of the opinion that we should:

Deprecate and remove stable branch
Deprecate and remove metastable branch (going forward we can use release branches for what we did with metastable in the past)

May want to update BranchingPolicy to reflect this (also should probably have some statement about closing release branches and tagging)

Reassigning to David Raznick as he is our release guru now.

status changed; repo, theme, resolution set

thejimmyg — Thu, 17 Mar 2011 14:31:26 GMT

repo set to ckan
status changed from new to closed
theme set to none
resolution set to fixed

I'm updating the branching policy now. David has closed stable and closed metastable. Marking as fixed.