On Tue, Dec 10, 2013 at 5:10 PM, Mike Solomon <m...@mikesolomon.org> wrote:
> > I don’t think asking users a question is blasting ahead with a solution. > It is a question that will help me better understand how users use > unstable versions LilyPond, which in turn will help me understand the > problem. > i've been using lilypond since 1.4. and my workflow pertaining to stable/unstable releases has always been as follows: 0. use the latest stable release more or less as soon as it comes out 1. keep an eye on the CHANGES file for nice new features 2. if a feature is implemented that i feel is an improvement to the stable release (this happens quite often), then i upgrade to the unstable release 3. i stay on top of the unstable releases, also still keeping an eye on the CHANGES file 4. if i run into bugs (not very often anymore), i try to verify and report them 5. when the unstable branch moves to stable, so do i, and back to step 1. for instance: - the cool new features in 2.17 were \tuplet, tighter spacing, dot.notation.of.objects and \markLengthOn, several articulations feature; - 2.15 didn't have much exciting for me in it -- here i stuck with 2.14 until 2.16 came out. - 2.13 was a good development version with the instrument names fixed, q for repeating chords, dotted/dashed slurs, two-sided margins, white-out, segno bar-line, cresc text spanners, the partcombiner, cueDuringWithClef, beam collisions, ... [2.14. was a GOOD release] [etc. etc. for older development versions. i can't find the change files online for the older ones, but i remember there were lots of interesting new features in 2.9 and 2.7]. having multiple development versions with different feature sets in them would be, in my eyes, a large waste of disk-space on the lilypond server. also, as others have mentioned, it would be maintenance hell for helpful mailing list inhabitants. not to mention that you're less likely to catch weird interactions between new features, which do occur every now and then in the development versions... i think one reason for less forward movement is that a lot of really groundbreaking, spectacular stuff has been covered. a lot of the new features in this release are improvements on sufficiently functioning new features, making them better. and we all know that 80% of the time on a project is invested in the final 20% of the work. yes, contributing to the project is difficult and convoluted; not helped by some very unique people working on the project, but i wouldn't want to miss any of them working on my favourite piece of software. graham and david, just to name two very prominent ones, have had an amazing influence on lilypond and it wouldn't be where it is now without them. just my two euro-cents, sb -- Do not meddle in the affairs of trombonists, for they are subtle and quick to anger.
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
