Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision)

[Graham Percival]

On Wed, Aug 01, 2012 at 12:31:55PM +0200, David Kastrup wrote:
> 
> At the time the 2.16 branch will be cut, the versioning for the unstable
> branch will need to advance to 2.17 in order to maintain an ordered
> relation between version numbers and LilyPond language.

Do you mean 2.16 instead of 2.17 ?

> What versioning should I be using for the release
> candidates?  Numerically, one has the options to start with
>
> 2.15.95

why not 2.15.42 ?  I'm not planning on making any devel releases
until 2.16.0 is out, but even if I were, I'd start at 2.17.0.

> or with
> 
> 2.16.0.95

I don't think that GUB supports this.  There are hints in the code
that such support was desired at some point, but I seriously doubt
that it would work.  In fact, I'm not even certain if the normal
build system and docs can handle such numbers (thinking about the
website generation in particular).

> The disadvantage of the former is that we'll want to run all the version
> updating procedures at the moment we split into a 2.17 and a 2.16
> branch.  If anybody has relevant input on that, this will be welcome.

oh, I get it now.  Yes, if a user has a score with \version
"2.16.0", they should expect convert-ly for version 2.17.2 to
handle it correctly.  hmm... actually, I don't there's a problem
here.  Provided that you don't change the syntax between current
git and 2.16.0, then I don't see a problem having a 2.17.0 release
while you're still working on 2.15.43 or 2.15.44.

... still, I think the easiest thing is not to have devel releases
until 2.16.0 is out.

> One of the reasons to release a stable release is to get the benefits
> and excitement to it about users and distributors.  For that reason, I
> would like to have the LSR updated.

Before 2.16.0?  I don't see that happening.  Get 2.16.0 out first,
have some rounds of testing leading to 2.16.1 and 2.16.2, and
*then* start trying to recruit somebody to handle the LSR update
and coordinate with Sebastiano.

> Since it is supposed to be a
> resource helpful to "average" users, that would mean that for a while,
> optimally two versions should be available in parallel, one for 2.14,
> one for 2.16.  At first the 2.16 version just as a "beta" or something,
> later the 2.14 as a "fallback" or so.
> 
> I have no idea how feasible this would be, but if we manage to
> eventually get to a reasonable stable release schedule, the usefulness
> of this resource would be increased by supporting more than just one
> stable release.

Not feasible, although patches appreciated.  Source code for LSR
is available; it's written in java.  Instead of patches, you could
rewrite the entire system in a different language.  Both options
have been discussed on -devel, starting from about 4 years ago I
think?  Latest one was within the past 6 months, or maybe 12?

- Graham