[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision)
From: |
Graham Percival |
Subject: |
Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision) |
Date: |
Wed, 1 Aug 2012 13:10:44 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision), David Kastrup, 2012/08/01
- Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision),
Graham Percival <=
- Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision), David Kastrup, 2012/08/01
- Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision), John Mandereau, 2012/08/01
- Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision), Graham Percival, 2012/08/01
- Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision), John Mandereau, 2012/08/01
- Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision), David Kastrup, 2012/08/01
- Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision), Graham Percival, 2012/08/01