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

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Wed, Aug 01, 2012 at 02:37:58PM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> 
>> >> 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 certain what you mean by "prereleases of GNU/Linux
> distributions".  If 2.16.0 is not out, then distributions like
> Ubuntu or Redhat shouldn't be touching 2.15.x.
>
>> >> 2.16.0.95
>> >
>> > I don't think that GUB supports this.  There are hints in the code
>> 
>> 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.
>
> "past" being about 10 years ago.

More like 6.

commit cf5748f82cda5eceeee93c64973660be320dd475
Author: Han-Wen Nienhuys <address@hidden>
Date:   Sat Sep 30 14:29:28 2006 +0000

    *** empty log message ***

diff --git a/VERSION b/VERSION
index 6d0ebc8..2c634f6 100644
--- a/VERSION
+++ b/VERSION
@@ -2,5 +2,5 @@ PACKAGE_NAME=LilyPond
 MAJOR_VERSION=2
 MINOR_VERSION=9
 PATCH_LEVEL=20
-MY_PATCH_LEVEL=lec2
+MY_PATCH_LEVEL=
 

>> 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.
>
> Sure, patches appreciated.

You know that this comes across as "In my opinion nobody but the foolish
person asking for this should think of working on that problem."?  I am
staking out the requirements I need to get the appointed job done.
Unless you have some reasonable suggestions how to get around those
requirements, I see little point in discouraging others from helping
with them.

> Initial wild guess: 20 hours to fix stuff in lilypond git, and 20
> hours to fix stuff in GUB.  Not counting the time it takes you to
> find a computer that can actually compile GUB.
>
>> > ... 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.
>
> Yes, this is tricky.
>
>> 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.
>
> I'm missing something.  What's wrong with this scenario:
> - I release 2.15.42 today or tomorrow.
> - you branch stable/2.16 from that.
> - in a week I release 2.17.0.
> - you do whatever you want with 2.15.43, 2.15.44, etc, until you
>   reach 2.16.0.  Other than probably having no syntax changes
>   because I really don't know how that can be juggled.

There will be no syntax changes in the 2.16 branch, at least not of the
convert-ly kind (one reasonably established syntax to a different
intended one).

>> 2.15.95 would presumably protest against snippets already being at
>> 2.16.0.
>
> The final change of version numbers it the last thing we've done
> in the past, and just tested on my local machine with make doc.

Hm.  At any rate, it seems strange to have 2.17.0 released and no
recognizable disruption in the 2.15 release series while 2.16 is not
finished.

-- 
David Kastrup