Transitioning to the new Release Process

[Johannes Pfau]

Am Thu, 10 Jan 2013 14:42:40 +0100
schrieb "mist" <none at none.none>:

> Staging as originally intended makes small sense with current 
> long release cycle / separate beta test combo. Thus long 
> forgotten proposal (sorry, can't remember original author) to 
> have releases often and LTS releases once in a long period. Than 
> development process looks like:
With the current approach features / enhancement have a longer testing
period than bug fixes. 
> 
> 1) master replaces staging
> 2) short period (i.e. 1 month) is given for D project maintainers 
> to check their stuff on staging and file regression bug reports. 
> Those bug fix branches are either merged to both master and 
> staging or merged to master and cherry-picked to staging (not 
> enough git expertise here to judge what is best).
> 3) Once period has passed and all regression reports have been 
> adressed, release is made from staging
> 4) Go to 1

But isn't this very similar to the current approach? The wiki page also
suggests to merge master into staging. Only the time span for release
preparation is different which is 8 weeks in the current proposal and
always the same length as the time between 2 releases. Your approach
fixes that time to 4 weeks.

You say merge bug fixes to both master and staging: This is essentially
what the wiki page describes: By first merging into staging those are
also merged into master by merging staging into master. (Merging bug
fixes to master is not possible, as we can't merge master into
staging when we're in a stabilization period.)

Of course we could also say merge the bugfix directly into master and
staging, but this would need 2 pull requests on github. It seems easier
to just merge staging into master periodically.

So your approach has the same problem: As long as staging is
stabilizing bug fixes must go to staging. They can additionally be
pushed directly into master, but if pull requests always target master
you have the same problem. (Only solution in cherry picking, but we
want to avoid that)

> 1) Release maintenance should be task of, well, maintainer. All 
> public development (pull requests) should go against a single 
> target branch and never stop. This is important to keep 
> open-source entry barrier low for newcomers.

Although I'd like the process to be as simple as possible for
contributors it's difficult to have the same branch for all pull
requests: If you wanted to get a regression fix from that branch into a
release branch your only option would be cherry picking. But some
people want to avoid cherry picking as much as possible, and this means
pull requests have to go to different targets.

> 2) LTS is a must for serious commercial usage (and being 
> completely frozen for 1 year is probably a bare minimum)
That might be right, but we can always add those real LTS releases
later. I don't think we have the resources to support such LTS releases
right now and it's probably not that useful - D has still way too many
bugs.

> 3) Release beta-testing should be as continuous as possible so 
> that any D user can make his input regarding next ongoing release 
> without following any mail lists and/or release schedules.

Posting beta releases on the download page would probably be a good
start.