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