Branching scheme for versioned releases

[wking]

Now that the spec is versioned and we're closer to getting runC versioned (#244), I think it's time to start thinking about the release process for landing breaking changes like #276. It would be nice to have a version of runC that operates with the current spec (v0.1.0? v0.1.1? See opencontainers/runtime-spec#183). But if we cut runC releases from master and #276 lands in master before, for example, #160 that won't happen. The only way I can think of to handle this would be to have one branch that continues to collect spec-v0.1 compatibility and bugfix PRs and another branch that collects backwards-incompatible changes for the next spec release (presumably 0.2.0). I don't really care what those branches are called, or what the workflow around them is. I'm sure y'all have lots of experience with workflows like this and can pick your favorite. I just think it's time to start doing something besides pushing all changes to master ;).

[fossxplorer]

+1

[hqhq]

Agreed, we should do this, a simple release branch would be great, we don't have to take much time maintaining that say before v1.0?

[wking]

On Sun, Oct 18, 2015 at 07:28:49PM -0700, Qiang Huang wrote:

Agreed, we should do this, a simple release branch would be great,
we don't have to take much time maintaining that say before v1.0?

I agree that proper releases don't matter so much before 1.0. But
(like I suggested for opencontainers/specs 1), I think it's worth
picking up the workflow as early as possible, so we have time to work
out the kinks before 1.0.

 Subject: Re: Initial Draft Release
 Message-ID: <20150911205808.GC5912@odin.tremily.us>

[crosbymichael]

We can always make branches off the the release tags. There is no reason to have the overhead of some long running branch on the repo for making hotfixes to a past release.