Transitioning to the new Release Process

mist none at none.none
Thu Jan 10 05:42:40 PST 2013


I did not feel competent enough to push for my opinion, I was 
just afraid that 3 consecutive iterations of updates from 
different people with different ideas in mind will result in 
least usable combination of all 3.

But well, if you want my opinion regarding master and staging - 
master should be a development branch as it is a default pull 
request target branch in github. All feature and bugfix branches 
should be branched to master.

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:

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

LTS release is only different that is is made i.e. once a year, 
has separate branch and is guaranteed to receive 
backwards-compatible bug fixes to own branch from master until 
next 2 LTS are out.

------------------------

This was just straight out of my head, details may vary but there 
are several crucial points I'd really like to be addressed:
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.
2) LTS is a must for serious commercial usage (and being 
completely frozen for 1 year is probably a bare minimum)
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.


More information about the Digitalmars-d mailing list