2013/8/19 Janek Warchoł <janek.lilyp...@gmail.com>: > 2013/8/19 David Kastrup <d...@gnu.org>: >> Urs Liska <u...@openlilylib.org> writes: >> >>> Version control _can_ be useful for a collection like the LSR. Think >>> of providing snippets for more than one LilyPond version. If I'm using >>> 2.16 I will download a different snippet than for 2.17.24 ... >> >> But that's not what version control is for. Version control does not >> fundamentally work with a series of codependent equally active HEADs, >> but rather has one principal HEAD of development, and historic >> references (quite likely containing _inferior_ code, and inferior for >> reasons that are often only marginally related to the LilyPond version). > > That's true. > However, i think that it ultimately /makes sense/ with LSR. Look at > it this way: > 1) let's say Lilypond 2.18 is released and all snippets are upgraded > to work with it. This is the master branch (what's visible by default > via the web interface), and it gets a tag "state as of 2.18 release". > 2) LilyPond is continues to be developed in 2.19 series. People > occasionally write new snippets that require 2.19 (or update existing > ones from 2.18 to 2.19) - commits doing this do to a separate > "develop" branch, and are not visible by default via the web > interface, but advanced users can easily access them. This is the > "improvement" part, as one upgrades a snippet to 2.19 precisely > because it will work better. > 3) at the same time, new snippets that work with the 2.18 release are > added (and some snippets are improved), and this goes to the master > branch. > 4) when lilypond 2.20 is released, master and develop branches are merged. > 5) the circle starts again.
There's one thing to realize: we wouldn't need to have a branch for every Lilypond version there. We would just need two branches: current stable and stuff that is ahead of current stable. Very much like how various projects are developed. And still, if someone needed to access a version of the snippet meant for a parrticular verison of lilypond, it would be easy to do this thanks to git. Janek _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user