github release procedure

[Johannes Pfau]

Am Fri, 04 Jan 2013 19:35:17 +0100
schrieb "deadalnix" <deadalnix at gmail.com>:


> 
> First, regression fix don't make any sense to me. You suggest to 
> fix bug in master and fix regression in older branches. This 
> should be the opposite IMO.
> 
> A regression is something that used to work, but don't work 
> anymore. So Correcting them in older version seems kind of 
> contradictory, especially when other bugs aren't.

I added a "Definitions" section to explain what's meant by regression
in that context. I also added a rationale, but already explained it
well. This was written assuming dmd though, were bugfixes can easily
cause regressions. For phobos/druntime we could use less strict rules,
I added a not about that on the wiki.

Now why we fix regressions in the release branches:
Let's say we have dmd 2.061, 2.062, 2.062.1. A regression was
introduced in 2.062 and my code that compiled fine in 2.061 doesn't work
in 2.062 anymore. But then the regression fix is pushed to the 2.062
release branch, a minor release is made and 2.062.1 successfully
compiles that code again.

If the regression already occured in 2.061 should it be fixed in 2.062?
This is a different question, but that situation can't happen as long
as we only support 1 release and only fix newly introduced regressions.

> Secondly, in every git commands block you have all the commands 
> to set-up the repository. I think this belong to its own 
> paragraph or even its own page. Then I'd replace them with git 
> remote update in git command block.

Yep, will fix that.