Ben Crowell writes: > In principle, I agree with Joe about users pitching in and > helping. However, IMO that's not really possible
Helping is easier than you might imagine and it usually is quite rewarding. It only costs some time and some determination. See what you can figure out yourself, and ask the things you cannot. > The language is constantly changing, and so are > things like the command-line options for lilypond-book. Change good, stubbornness bad :-) But seriously, what would you suggest us to do? The LilyPond project has rather limited resourses, i.e.: the spare time that people decide to offer. About the language: the convert-ly scrip should take care of most annoying changes. If not, please send a bug report. Expect even bigger changes in 2.3, when Lily learns about books and does page layout. We change things when we think after the change Lily has become better. About lilypond-book: if you care to take a quick look together with me, you may notice that the old lilypond-book (still distributed in 2.2 as old-lilypond-book for your convenience), is crappy and buggy code. It suffererd from creeping featurism. When I actually tried using it myself, first I had to fix a few bugs, and then found that inline music snippets could not even be updated with convert-ly. I decided to rewrite it with a minimum of features, but better to maintain, less bug prone, and with an option to run any filter on the inlinne Lily snippets only (think: convert-ly) and reassemble the hybrid document. LilyPond is at a point where we can ask power users to help along a bit, I think. I feel this is the Right Thing (TM) to do. At least until the team gets bigger or some of us find a good way to spend a bit less time with their current payed jobs and more with LilyPond. > I think it should be more like 0.2.2, and when software is at 0.2.2, > it's not really done enough to attract third-party documentation. Versions do not tell you how good a software is. About six years ago, we decided for 1.0 instead of 0.2 because LilyPond then had "some real world usage value", for the first time. If you write a software, then you get to decide on and the responsibility for the versioning scheme. The reason the versioning has seen a speed-up, is because major incompatible changes imply a major version increment. The next stable version will most probably be called 3.0. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org _______________________________________________ lilypond-user mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-user
