github release procedure

[H. S. Teoh]

On Fri, Jan 04, 2013 at 03:00:10PM +0100, Johannes Pfau wrote:
> Am Fri, 04 Jan 2013 07:59:05 +0100
> schrieb "Rob T" <rob at ucora.com>:
> > 
> > I'm not certain what the major difference is between (1) and (2), 
> > because they both sound very nearly identical.

That's because they are essentially two ways of implementing the same
concept.


> > 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?

I don't think the difference is that serious. (1) is just more
_convenient_ for beta testers, because there's an actual branch called
'staging', so they just have to grab that. (2) requires that they know
which version branch is the latest, which again, isn't that big of a
deal.


[...]
> http://wiki.dlang.org/User:Jpf/Release_Process
> 
> I updated the page with some more git commands, ascii art and color so
> it's hopefully easier to understand now. Please tell me if I got
> anything wrong. The only thing I (intended to change) changed is that I
> removed staging.

I like what you did with the page. I think it makes it a lot clearer. I
read through "Release Schedule" and "Branching model", and I think it
pretty much captures what I described as approach (2).


> Although I can see the benefits of staging as you describe it, we can
> get most of those by just creating a new release/version branch as
> soon as the current release is released. This removes some complexity
> from the workflow.

If this approach is more suitable for the core devs, then I think we
should go with it.


> AFAIK it should be easy enough to introduce staging later on, when
> everyone is comfortable with the new workflow. (Please consider that
> many of us are not git experts - so if we can avoid some complexity
> now and add it later if needed, I'd prefer that)

Whether or not one is a git expert ought not matter, if we define the
process sufficiently clearly that one can simply look up the wiki page
and type in the commands as-is, like a script, as Walter puts it. The
important point is to agree on a single implementation of the process,
and supply complete and unambiguous series of git commands to carry out
the process.


T

-- 
The fact that anyone still uses AOL shows that even the presence of
options doesn't stop some people from picking the pessimal one. - Mike
Ellis