github release procedure

[Jonathan M Davis]

On Friday, January 04, 2013 00:47:08 foobar wrote:
> 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.

??? Bug fixes go to master. New release branches are branched from master. So, 
you're not going to have future branches not getting previous bug fixes. The 
only way that you're going to get problems with bug fixes not making it into 
future releases is if you commit them to the branch first rather than directly 
to master (which is a bad idea IMHO) and then you forget to merge that back 
into master.

- Jonathan M Davis