Re: stable/2.12 and tagging of tarballs

[Graham Percival]

On Tue, Jun 09, 2009 at 03:56:25PM +0200, Jan Nieuwenhuizen wrote:
> Op dinsdag 09-06-2009 om 07:16 uur [tijdzone -0600], schreef Carl D.
> Sorensen:
> 
> > There was an announced policy of rapid releases that discouraged spending
> > time on backporting, since we were going to move forward more rapidly on
> > releasing new stable branches.
> 
> Wow, should have read those.  I guess you can pretty much do what you
> want, however, a few things really strike me as odd or unwise

If only we had a high-visibility lilypond-proposals mailist, so
that nobody would miss stuff like that... :)

>    DON'T TOUCH STABLE/2.12.
> 
> why create a "stable/2.12" branch and then not use it and do subsequent
> 2.12.x releases from master?  Why not create stable/2.12 when master
> branches off for 2.13 development?

Dunno.  Is this an automatic tagging?  I'm still trying to figure
out what branch/tags are done automatically by GUB.

I definitely agree that stable/2.12 should contain the last stable
(i.e. the stuff that was in 2.12.2, or now 2.12.3).

>    - I will release a final 2.12 release, and begin 2.13.0.
> 
> there is really no such thing as a final release.

Sure there is.  If we don't make any later releases, then we have
a final one!  :)

> In this 2.12.2, we have seen ja doc glitches, and gcc-4.4
> updates.  There's always the possibility that a user finds a
> real silly problem that you want to make a new stable release
> for.

Given the lack of people interested in maintaining backports, the
proposal is that we just say "wait for 2.14".

> makes me frown.  Has 2.13 development been opened already?

Yes, IIRC early Feb.

> Is it wise to ask people to sit on their patches for *months*?
> I know that for me such a thing would be one of the biggest
> discouragements to do development.

They don't wait for months.  If there's important stuff to be
added, then we stop the stable release and move to development
releases.

> > I'd propose that we release 2.14 very soon, as a good way to get out of the
> > mess we're currently in.
> 
> I propose to release a buildable 2.12.3 tarball, and to have name a
> stable and a development branch.  Numbering isn't all that interesting,
> but linux also has that: you need [at least] two [more or less] active
> branches if you are willing to do some kind of sane release management.
> IMHO, of course :-)

I disagree.  I think that having 2.12, followed by 1-3 months of
bugfix updates, then a gap of 4 months, then 2.14, works fine.
The "gap" is as far as normal users are concerned.  Developers
will have 2.13 releases during that "gap".

This is mostly what we've been doing anyway -- sure, 2.10 reached
.8 or .10, but at some point, we all said "not worth backporting
stuff" and we ignored it for a year or so.  All updates were 2.11.

I'm just proposing that we make this "laziness" official.  To
counteract the gap between stable releases, we make many more
stable releases -- 3-4 releases each year.  If I hadn't been in
Singapore, we'd be working on 2.15 right now, having already
released 2.14, finished the stable maintenance, and moved into
2.15.


The plan right now is:
- clarify the maoing git repos
- finish the CG (other than the programming chapter)
- check with Han-Wen about updating libs (pango, fontforge,
  mftrace, whatever)
- start 2.14 release procedures.

We'd potentially release 2.14 by the end of this month.
Francisco: no, I haven't forgotten about giving notice to the
translators, and giving them a week or two to finalize stuff.

Cheers,
- Graham