On Wed, Aug 01, 2012 at 03:21:34PM +0200, David Kastrup wrote: > Graham Percival <gra...@percival-music.ca> writes: > > >> 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.
I apologize; you are quite correct. > > 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). Shall I go ahead and do 2.15.42, then? > >> 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. Well... I agree that it's a sub-optimal situation. But this is the least disruptive (in terms of development) and least resource-intensive (in terms of fighting with build systems) manner I can think of. I think we can live with a bit of strangeness. If we had experts actively maintaining our build system and GUB (people such as Jan, John, or Julien [1]), I would be much more interested in discussing ideal policies for users and developers. Or even if we had no experts but I had time and interest to fight with GUB. However, at the present time we lack either experts or non-experts with excessive interest in GUB. So I reluctantly recommend that you optimize the 2.16 policies for a lack of build system changes. If the situation changes (say, Julien finishes university and gets sponsored to work on lilypond full-time, or you get a computer capable of compiling GUB), then of course I would withdraw that unpleasant recommendation. [1] I would have added your name to the list, but it doesn't begin with a "J" in alphabetical order of chronological order of working on the build system. - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel