Trying to follow "Preparing a new major release" instructions

[Johannes Pfau]

Am Fri, 08 Feb 2013 13:09:59 +0100
schrieb "deadalnix" <deadalnix at gmail.com>:

> On Friday, 8 February 2013 at 09:16:02 UTC, Johannes Pfau wrote:
> > Am Thu, 07 Feb 2013 21:26:38 -0800
> > schrieb Walter Bright <newshound2 at digitalmars.com>:
> >
> >> on http://wiki.dlang.org/Development_and_Release_Process
> >> 
> >> So, I did the following commands per instructions:
> >> 
> >> #Make sure you've read "Local repository setup"
> >> git remote update
> >> 
> >> git checkout staging
> >> git pull upstream staging
> >> 
> >> git tag v2.062-b1 #b1=>first beta
> >> git push upstream v2.062-b1
> >> 
> >> and they all worked successfully, but the new tag, etc., do 
> >> not show
> >> up here:
> >> 
> >> https://github.com/D-Programming-Language/dmd/tree/staging
> >
> > The tag is there but it references the same commit as 2.061. 
> > This is
> > because the tag was made on the staging branch, which is 
> > correct. But
> > the staging branch hasn't been updated since the last release. 
> > (Which
> > is also correct, but we have to do one intermediate release with
> > special transition instructions. Otherwise we have two releases 
> > with
> > exactly the same content)
> >
> > To determine what to do now, we have to know when this release 
> > is
> > supposed to be shipped. If we can delay it for ~1 Month we can 
> > make the
> > transition to the new release process now and the next release 
> > will
> > follow the new instructions 100%. If we want to release ASAP 
> > the next
> > release will be the intermediate release.
> >
> >
> > BTW: It's very important that the released beta zips are 
> > actually based
> > on the created tags! The current release is based on some recent
> > commit, although the tag is set to a commit from a month ago.
> 
> Well it has been raised that the staging branch is kind of 
> useless. It was useful in early version, but several changes in 
> the process diminished its interest. Should we simply remove it ?
> 

It's still useful. It's supposed to be used for stabilization before an
actual release. The release branch is only used after the first release
has been made.

I actually like this concept, but you could also prepare releases on the
release branch. There are some drawbacks though. (For example a pull
request targeting an release branch could be valid before the release,
as we still allow all kinds of bug fixes then, but invalid after the
release as the criteria for which fixes are allowed changed).

The problem here is that the wiki page is missing instructions for the
transition from the old process to the new process. 5.3 suggest merging
master into staging _after_ an actual release, but this won't work for
the transition release as we won't get any new commits into staging (as
it happened now).


What we really need to do is agree on a release process - starting
the transition to the new process only makes sense if all contributors
really  agree to use the new process. So we need all core developers to
issue their concerns, probably adapt the release process and then make
plans/instructions for the transition phase. And the _do_ the
transition.