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