Re: Post-2.12 release plans

[Graham Percival]

On Mon, Dec 22, 2008 at 06:54:43PM -0000, Trevor Daniels wrote:
>
> Han-Wen Nienhuys wrote Monday, December 22, 2008 6:22 PM
>
>> It would be really nice if we could invert the rhythms of
>> stable/devel: have a long stable cycle with many releases (like 2.11
>> had), and then    have a flurry of 2.13 releases which introduce
>> incompatibilities, and push out 2.14 asap.

That's my hope -- but it depends on what kinds of syntax-changing
patches people want to merge.  We don't want to slow down
development too much.

> I'm still not sold on the benefits of this.  There are many users who do not
> want a changing environment - the ones that are still on 2.10, for example.
> If we go along with this, there will be no uniform stable environment.  Even
> if each of these users just downloads a single version and sticks with that,
> they may choose different versions, which means they have different
> documentation and different features. That complicates discussion and
> help on -user.  It also makes keeping the documentation in synch more
> difficult.  That doesn't matter in a release clearly tagged as  
> "development",
> but it does matter in a release tagged as stable.

Minor issue compared to 2.10 vs. 2.11.  We've really only had a
single branch for the past year or more, and it's worked fine for
people on 2.11.  The only support problems we've had with 2.11
were the newbies using 2.11 and syntax changes, but if 2.12 has no
syntax changes that won't be an issue.  (and with an active stable
branch, there's less pressure for newbies to wander into devel
territory)

> I still think the benefits of a truly stable release for those users who
> simply want to engrave music should not be discarded lightly.  So far
> this discussion has been limited to the -devel list.  Should we not seek
> opinion on-user?

oh god no.
(I'm so shocked I forgot to insert "Mao" in that.  :)

This is totally a meritocracy question.  Non-developers want the
sun and moon, right now, for the price of a download.


In the past we've tried to do the backporting idea.  It's lasted
for a few months, but then we just abandon the stable branch.
When complicated changes happen -- for example, the vertical
collision avoidance -- it gets to be too much work to backport
stuff.  I'm therefore invoking whatever veto power I have on this
particular discussion.  Backporting is not something that I can do
or teach; in the past it hasn't worked; in the absence of a
knowledgeable person who is willing to spend whatever amount of
time it takes, this isn't an option.

I'm convinced that the docs/website/support can handle this type
of devel cycle without problems; the only question is whether
developers are on board, and currently this sounds promising.

Cheers,
- Graham