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

[David Kastrup]

Graham Percival <address@hidden> writes:

> 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 ?

I meant 2.16 where I wrote 2.16, and 2.17 where I wrote 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 ?

Because the 2.16 branch is supposed to produce the versions for
prereleases of GNU/Linux distributions.  We won't be able to sell it for
that purpose using 2.15.42 as a number.  And anyway, 2.15.42 is already
taken for the next _unstable_ release.

> 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).

It would make sense to put this under scrutiny.  There is support for it
in our VERSION file and several Makefiles, it has been used in the past.
If it is non-operative, it should be either made operative or removed.
There is no point dragging it along as purely dead weight we should not
be using.

>> 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.

A prerelease is not a "devel" release.  2.15.42 has had 56 issues so far
in 3 weeks.  The stabilizing phase of branch 2.16 will take several
weeks at least, or the "stable" label will be a mockery.  It does not
make sense to stop the presses of development since that does not
actually help with getting the stable release settled.  As 2.16
dictator, I will be responsible for getting a version 2.16 out in a
quality and time frame appropriate for that task.  I will not be
responsible for deadlocking ongoing development, so I don't want a setup
where this will be the result.

By the time we release 2.17.0, I want to have a version of the 2.16
branch out that is clearly recognizable as different from the 2.15
releases so far, even if it is not the final stable release.  It will
have the versions in the snippets updated according to 2.16, and the
documentation updated according to 2.16.

I can't bet my life on it that only one such release will be needed, so
reserving just 2.16.0 for that and stating "real releases start with
2.16.1" is not enough.  So I see the need for version number breathing
room, and it would seem that making MY_PATCH_LEVEL work presumably as
intended would be likely the best bet.

2.15.95 would presumably protest against snippets already being at
2.16.0.

Complicated.

-- 
David Kastrup