On Dec 10, 2013, at 3:41 PM, Carl Peterson <[email protected]> wrote:
> On Tue, Dec 10, 2013 at 8:23 AM, Mike Solomon <[email protected]> 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
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
