Re: survey on multiple development versions

[Mike Solomon]

On Dec 10, 2013, at 3:41 PM, Carl Peterson <address@hidden> 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?

The idea is that the canonical version will pick up all inclusion-worthy features a few weeks / months after the experimental versions.  It is true that it’s annoying to wait, but the current state of things is for these features either to not exist at all or exist at a much later date.  I think that the scenario you describe above, while frustrating, is preferential to the current state of things.

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

The versions are always “branched" off of canonical development, like so:

canonical development

|— A

|— B

|— C

Think of canonical development as a foundation for A, B and C. This means that any bugs fixed in the canonical version will be fixed in the experimental one unless the experiments are so experimental that they break everything, which we’d obviously try to avoid.  Conversely, a problem in branch A will never be fixed in just branch B - it will first be fixed in A and then applied to all of the branches (or it will persist in all the branches if no one catches it).

Let’s assume that canonical devel is at 2.19.23.  You are using 2.19.3.A.  It would go as follows:

A: "I have this problem. I am using version 2.19.3.A”

an appropriate response would be either:

“This was fixed with version 2.19.23.”

or “This was fixed with version 2.19.23.A”

but never “This was fixed with version 2.19.23.B"

It is true, though, that attentiveness to versioning would become important for testers and responders alike.

Cheers,

MS