github release procedure

[H. S. Teoh]

On Thu, Jan 03, 2013 at 09:17:08PM +0100, Rob T wrote:
> On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei Alexandrescu
> wrote:
> >On 1/3/13 1:58 PM, Walter Bright wrote:
> >>As I suggested to Jacob, if the wiki lists git command sequences, it
> >>should be complete (like a script), and not full of assumptions
> >>about other commands that need to be inserted.
> >
> >I think this is a pertinent point - the process proposed at github is
> >incomplete and scantily motivated. Can the experts make one more pass
> >through it?
[...]
> I'm rather concerned when I see comments that suggest that the
> purpose of the staging branch was not understood in the slightest.
> There's a lot of discussion on the issue here
> http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com

In my mind, 'staging' is just a placeholder name for the place where we
can freeze new features and stabilize them before a release. The actual
mechanics of doing this is independent of the concept itself.

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.

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.


> The people who are attempting to use the new process have to at
> least take some time to read through the process discussion threads,
> certainly that is not ideal, and the wiki should explain everything
> much better.
[...]

I confess to having contributed some poorly-written material on the wiki
page. Please feel free to revise it.


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5