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