Transitioning to the new Release Process

[Rob T]

On Thursday, 10 January 2013 at 15:51:13 UTC, Andrei Alexandrescu 
wrote:
>
> My understanding was that staging is worked on only during the 
> (short) time span from initiating a new release and finalizing 
> that release.
>
> Andrei

There are significant side effects of that approach:

1) There's no beta made available for release. While you can try 
really hard to claim that there is a beta, in practical terms 
there isn't one, because very few people will even know it is 
there, and even less will have the ability to test it. Even if 
someone managed to try it out, not enough time is available to do 
anything significant with it and report back the results for 
refinement.

2) You'll never gain a high degree of stability between releases. 
The reason why is because the poorly tested development copy, is 
the released version, and following point 1) above, it will never 
be sufficiently tested and refined prior to release.

The results we got with the 2.061 release is what the process 
will give you, which is an unstable compiler that no one will 
want to use in a production environment unless they don't mind 
getting fired, in other words what was released is in fact a beta 
release of the unstable development branch.

If our intention is to produce a stable release that is 
maintained, then the process needs to be designed in a way that 
produces one.

The only way stability can happen, is if all development stops on 
a release branch for a sufficient period of time, ie., it enters 
into a maintenance mode where only critical bug fixes are 
introduced.

We don't want to stop the clock however, there's always newer 
exciting things to be done, so the development must proceed, and 
new major releases must follow. The tricky part is to do it in a 
non-disruptive way, that smooths out the instability between 
releases, that's the purpose the beta branch servers, a middle 
ground between stability and instability, but it's far more than 
that, it can also provide the development team with crucial feed 
back from real-world users.

We have to realize that the release process is not intended for 
developers, you have to consider what the users of the compiler 
want to see.

1) Users want to have access to a well maintained release of the 
compiler, where incremental upgrades contain only bug fixes up 
until the next major release, which will contain new features and 
other major improvements.

2) Some users want to have access to a reasonably stable beta 
release. The only reason why a user will want to try a beta 
version, is when the stable released version does not yet have 
something that they want to try out that is available in the 
beta, such as a new feature like UDA's. The beta should be in 
packaged form and available on the download page because you have 
to make it very easy for people to try it.

How we achieve the results may not matter so much, but from what 
I can see, to achieve point 1), the release must come from the 
beta, and there must be a release branch that can receive bug 
fixes. To achieve point 2) which is providing a reasonably stable 
beta for the users to try out, there must be a beta branch. The 
beta branch receives only new features and bug fixes that have 
been fully agreed to and well thought out.

Meanwhile all of the half baked new concepts are contained in the 
development branch (we've pegged it into master), and all the 
experimental stuff resides in the various scattered feature 
branches that only developers and high adventures are willing to 
try out.

--rt