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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
