github release procedure

[H. S. Teoh]

On Fri, Jan 04, 2013 at 04:14:00PM +0100, Johannes Pfau wrote:
[...]
> I just thought about something - maybe staging isn't 100% redundant.
> I assume my conclusions on
> http://wiki.dlang.org/User:Jpf/Release_Process are correct:
> 
> If we want release stabilization time == time between 2 releases i.e.
> we start a new release/version branch after every major release: 
> 
> Let's say 2.062 is in stabilization phase and we use the 2.062 branch.
> Then bugfixes are based on / merged into 2.062 branch. So someone
> opens a pull request targeting the 2.062 branch with a bugfix. For
> some reason (lack of time) this request isn't merged till 2.062 is
> released.  After the release only regression fixes should go into
> 2.062.  But we now have a bugfix (not regression) pull request
> targeting the 2.062 branch!
> 
> Staging completely avoids that issue. So is this reason enough to have
> staging?

I'm not sure, but in my experience at my day jobs, any bugfix that *can*
be applied to master (i.e., the code hasn't diverged so much that the
fix doesn't apply anymore), *should* be. For this reason, it's best to
always base bugfixes on master, unless the code has diverged so much the
fix only applies to a particular release branch. Otherwise you end up
with the problem somebody mentioned, that the bug is fixed in a previous
release, but is "unfixed" in a later release because we neglected to
merge the fix into master.

Of course, it's possible to base the fix on the release branch and merge
it back to master, but the latter step is more prone to be forgotten.
But then again, post-release regression fixes should probably be based
on the release branch, so that we know that the fix works, as master may
have diverged significantly since the original release branch was made.
So either way, we have to make sure fixes are applied back to master.


T

-- 
May you live all the days of your life. -- Jonathan Swift