Next focus: PROCESS

[Rob T]

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