Transitioning to the new Release Process

Jesse Phillips Jessekphillips+D at gmail.com
Wed Jan 9 09:12:14 PST 2013


Before starting this I did come across Walter's complaint of 
issues, but feel this needs a new thread. But didn't read all 
replies.

The new process introduces a new branch called staging. This is 
_not_ used as one would first think.

staging is created/updated _after_ release. This means a delay in 
changes in master (breaking changes/new additions) and release (a 
good thing). It also means that we have to do some awkward 
delaying to get some useful changes into staging so that it is 
different from this last release.

The delay is good, we can continuously releasing betas from 
staging and fixing bugs in both staging and master for the time 
master is being developed. And master doesn't have to be perfect 
when doing a release, it is moved into staging afterwards and can 
get final touch ups there.

Maybe the next release can just be a -bugfix- regression release 
off staging?

Walter, I believe the proper way to merge changes from staging 
into master is:

$ git checkout master
$ git merge staging

Cherry pick isn't needed since all changes should be desired.


More information about the Digitalmars-d mailing list