github release procedure

[Rob T]

On Thursday, 3 January 2013 at 22:11:59 UTC, H. S. Teoh wrote:
> We could either:
>
> (1) Have an actual branch called 'staging', where changes made 
> to master
> since the last merge are merged in immediately after release, 
> and when
> things have sufficiently stabilized, we tag/branch that 
> particular
> commit as release 2.X.Y;
>
> (2) Or, we can follow Walter's suggestion of branching master 
> into 2.X.Y
> after a release and just tag it as a release when it's 
> sufficiently
> stable. In this case, the latest 2.X.Y branch acts as 'staging'.
>
> Part of the draw of (1) is that betatesters and adventurous 
> people have
> a fixed place to go to, to get the latest and greatest 
> features, but
> without the instability of master.

(1) is what I was advocating precisely so that beta testers could 
use it shortly after a release and up to the final next release. 
There are a few benefits to this that may be under appreciated. 
There's plenty of benefits to having a lot of beta testers, so we 
want to draw them in and encourage them to use the latest beta 
version as soon as possible. Real world programmers do not want 
to make use of something that is too unstable, so they will tend 
to avoid the master development branch and will prefer the latest 
stable release instead. The only reason they will try out the 
latest beta version, is to gain access to a bug fix or new 
feature that they really need for their real world programming 
tasks, but they will only try it out if they think that the beta 
is stable enough and is not going to get horribly broken by 
anything radical being merged in without proper oversight and 
planning (that's what master and the related feature branches are 
for).

If we immediately move master into the next staging after a new 
release, and freeze the introduction of new features, only to 
concentrate on stabilizing it for the next release, then we're 
more likely to attract beta testers from the real world, these 
are the guys who will do testing under the most realistically 
conditions possible, something that in invaluable in gaining feed 
back and routing our difficult to discover bugs.

> I think (2) is more commonly what is actually done by software 
> companies
> and projects. In this case, 'staging' isn't so much as an actual
> physical branch, as the general concept of having a branch 
> (2.X.Y, which
> changes per release) to stabilize things for a release, while
> development on master continues unhindered.
>
> The Linux kernel also uses a similar kind of process: X.Y.Z is a
> development release (can be thought of as 'master') when Y is 
> odd, and a
> stable release (can be thought of as 'staging' or Walter's 
> release
> branches) when Y is even.
>
> Basically, the idea is that master should be able to receive 
> the latest
> and greatest features, completely unhindered, while stabilizing 
> the code
> for a release is done in a separate branch which doesn't 
> receive new
> features, but only bugfixes, prior to an actual release.
>

I'm not certain what the major difference is between (1) and (2), 
because they both sound very nearly identical. In both cases, 
they seem to provide the same goals of stabilizing the next 
release, while allowing development to proceed unhindered, so if 
(2) can be made to achieve the goal I described for attracting 
real world beta testers, it may not matter which is used, however 
I would suggest that we always focus on serving the needs of the 
end user as a top priority as much as is possible. D requires 
plenty of significant end users working on significant projects.

You did mention that (1) is more suitable for beta testers, so I 
ask how is (2) not as suitable?

--rt