Re: survey on multiple development versions

[Colin Campbell]

On 12/10/2013 06:41 AM, Carl Peterson wrote:

On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon <address@hidden> wrote:

Hey all,

I recently e-mailed the development list about multiple concurrent development versions and I’d like to ask users, especially those currently using the development version, to take the time to respond to a question regarding the proposal.

If lilypond.org were to propose multiple development versions (say 5 instead of 1), each offering a different set of experimental features (including the canonical development version), and if lilypond.org offered information on which versions were in need of testing by what types of users, would you be interested in helping out by doing some typesetting with these alternative versions?

The problem I see is an issue of mixing and matching. What if there is a feature I want to use on Development Version A and one I want to use on Development Version B, within the same score? I also foresee a multiplication of the issues regarding who is using what version on this list, as in:

Today:

A: "I have this problem. I am using version 2.17.3"

B: "We fixed this problem in 2.17.23"

With multiple versions:

A: "I have this problem. I am using version 2.19.A.3"

B: "This was fixed on version 2.19.B"

A: "Okay, that fixed that, now I have this problem."

C: "This was fixed on version 2.19.C"

A: "I'm confused. How do I fix both of these problems?"

From the perspective of a light-duty user and former patch nanny, Mike's idea seems quite frankly alarming. The thought of exposing users to multiple diverging and possibly incompatible development versions of a system, which is already so complex that modifying the build system has been called "poking a hornets nest with a stick", would anchor me quite firmly on latest stable, and I likely wouldn't try to answer questions on -user, either.  I'm quite happy building the binaries and doc from git, but if the development efforts get even more fragmented, with devs each competing to get users testing their latest brainstorm, I doubt it would end well.  Yes, of course there are power users who can handle alpha- and beta-level code, but in the context of trying to make lilypond *more* accessible to people who simply want to engrave beautiful music with minimal effort, we would be best served by making the existing development process more effective and efficient, so that only code which is truly beta-plus or RC level would be available to users.

For clarity: I'm not saying devs shouldn't fork LP when they want to work out some cool new feature. Git branches are a fine tool for the purpose. It's just that there are already so many versions of LP in the wild that our support and distribution resources are strained, and introducing another 5 versions of LP, with guaranteed problems, may well divert developer effort from the main branch or worse, turn the devs and power users off answering questions and feature requests entirely.

I'm all for exploring options, but I truly believe this adds a level of complexity we can't handle with existing resources and tools, for relatively small gains or potential loss of live testing of beta-level code.

Cheers,
Colin

-- 
I've learned that you shouldn't go through life with a catcher's mitt on both hands. 
You need to be able to throw something back. 
-Maya Angelou, poet (1928- )