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