lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Post-2.12 release plans


From: Graham Percival
Subject: Re: Post-2.12 release plans
Date: Mon, 22 Dec 2008 04:58:26 -0800
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Dec 22, 2008 at 12:56:35PM +0100, Valentin Villenave wrote:
> 2008/12/22 Graham Percival <address@hidden>:
> > Once 2.12 is out and we've succeeded in setting up GUB3 on
> > kainhofer, I'll become the Release Manager.  I have two ideas on
> > how to change things:
> 
> Good to see you're still involved, Mr
> "I'm-leavin'-soon-anyway-so-just-pretend-I'm-not-here" :-)

It's a good exercise.  Besides, I don't think I touched git in the
past four months, so you could certainly argue that I *wasn't*
here.

> > 2)  Keep the distinction between stable and devel, but tie it to
> > the input syntax, and allow for much faster releases.  In
> > particular, there would be *no* convert-ly rules for 2.12.  New
> > constructs would be fine, but any patches that would change
> > existing syntax would be delayed until 2.13.
> 
> Hm, let's not be too strict in advance. No "major" breakage in 2.12 is
> already a sensible goal; no syntax change at all... well, there's
> always the possibility that we have to correct some inconsistency we
> may have missed until now, or whatever.

Under this scheme, that inconsistency would remain un-committed
for two or three months.  I suggest that this isn't too horrible,
and it would be worth it for the increased stability.

When I say "stability", I don't care about complaints on -user
(obviously; I'm still me :).  I'm talking about projects like
rosegarden or Strasheela -- I'd *love* to be able to say "if your
software exports a well-formed file for 2.12, it will work in all
2.12 versions.  If you want to compile it in 2.14 or later, then
you'll need to run it through convert-ly or update your export
function".


> > Yes, this would mean that some patches would be delayed a few
> > months, but with git it's easier to test them in separate
> > branches.  We'd also be flexible about when to start 2.13 -- if
> > there was a great new feature that required changing the existing
> > syntax, we could start .13 earlier than 3 months.  Conversely, if
> > all development is simply adding new features or fixing bugs, we
> > don't start .13 until later.
> 
> Does this mean you do not want to make any difference between odd and
> even versions?

No.  .13 would be the "devel" version, where syntax changes are
introduced, and any major breakage occurs.  It would last as long
as necessary to fix the major breakage and everybody to get their
syntax changes introduced.  Then .14 would be released.

Ideally, I'd shoot for 6 months of .12, 2 months of .13, then .14.
I mean, if there's no syntax changes and no major breakage, then
there's no point stopping .12 and calling it .13.  Now, 6 months
without syntax changes is probably a bit long at this point, so
.12 might only be 3 months.  But hopefully .14 or .16 could have a
longer stable branch.

Cheers,
- Graham




reply via email to

[Prev in Thread] Current Thread [Next in Thread]