On Sunday, 16 December 2012 at 23:18:20 UTC, Jonathan M Davis
wrote:
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
Precisely. Thank you.
