github release procedure

[foobar]

On Thursday, 3 January 2013 at 22:04:28 UTC, Jonathan M Davis 
wrote:
> On Thursday, January 03, 2013 21:42:37 Johannes Pfau wrote:
>> What I am most concerned about are the timespans discussed:
>> "I propose to go for a yearly release of the
>> stable branches with one year support (In the beginning)."
>> 
>> The wiki discussion page even mentions "I don't think 4 months 
>> are a
>> ridiculously long time for staging if the release is made 
>> every 3
>> years."
>
> That makes it sound like they want the current stuff to be 
> marked as staging
> and then have some other release that sits around for a very 
> long time being
> treated as somehow more stable than the staging branch. In 
> general, there's
> nothing about bug fixing which is stable, and separating out 
> bug fixes between a
> more stable branch and a less stable one doesn't make all that 
> much sense.
> Separating out new features and not putting them in the 
> "stable" branch makes
> sense, but that really doesn't make sense for bugs.
>
> Also, the name "staging" implies that it's purely for preparing 
> a release, in
> which case keeping it around makes _no_ sense. Not to mention, 
> as already
> mentioned, it would make more sense to simply create a new 
> branch for each
> release to begin with than have a staging branch if that's what 
> it's for. And
> if that's not what it's for, then it's a horrible name.
>
> - Jonathan M Davis

As I explained several times before, this is a HORRIBLE idea. If 
each release has its own branch than a bug fix needs to be 
applied to _all_ such branches _manually_ and it is easy to get a 
situation where a fix on say version 3.1 was accidentally not 
merged to version 4.0 (forgotten) and suddenly the bug was 
"unfixed".
Whatever the name of this branch is, the semantics/purpose of it 
is to provide integration.