On Sunday, 16 December 2012 at 16:23:57 UTC, 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.
I don't see a problem with retaining release branches for some
time, and I think we were planning to do this as a means to
support previous stable versions for some time period.
However, patching a downstream release while leaving upstream
unpatched is not going to work well within the public branches,
the flow must be from up stream to down stream, otherwise it'll
be a confusing mess where older versions may have specific bug
fixes but higher versions don't have the same bug fixes. In
addition stable branches are forbidden from receiving new
features because that will destabilize them and in addition
upstream will be out of sync, causing a lot of confusion.
From what I can see, part of what you are proposing will have to
be performed off-site as a private affair between the corporate
user and the service provider. What we can certainly provide is a
stable branch as-is when it was released, and that branch can
certainly receive any patches that made their way that far down
stream, however the patches will be bug fixes only.
--rt
