Next focus: PROCESS

[Jonathan M Davis]

On Sunday, December 16, 2012 11:23:57 Andrei Alexandrescu wrote:
> Right now we're using a tagging system for releases, implying releases
> are just snapshots of a continuum. But what we need is e.g. to be able
> to patch 2.065 to fix a bug for a client who can't upgrade right now.
> That means one branch per release.

Well, you can still do that. You just create a branch from the tag when you 
need a branch. You don't have to branch from the latest. You can branch from 
any point on the tree, and tags provide a good marker for points to branch if 
you need to.

Then the official release is still clearly tagged, but you can have branches 
based off it when you need it. It also avoids some minor overhead when patching 
releases is rare. My main concern though would be that the actual release 
needs to be clearly marked separately from any patches, so it pretty much 
requires a tag regardless of what you do with branches.

What I would have expected that we do (though I haven't read through most of 
this thread or the wiki yet, so I don't know what's being proposed) would be 
to branch when we do beta, and that branch would be what would ultimately end 
up where we release from, with a tag on the commit which was the actual 
release. If further commits were made for specific clients after the release, 
then either you'd make a branch from that which was specific to that client, or 
you'd put them on the same branch, where'd they'd be after the tag for the 
release and wouldn't affect it.

- Jonathan M Davis