Status: Accepted
Owner: ----
Labels: Type-Other Priority-High Maintainability
New issue 1185 by percival.music.ca: version numbers for large new features
http://code.google.com/p/lilypond/issues/detail?id=1185
New features require specific version numbers; new features with syntax
changes require even more fussiness about version numbers. If we have a
devel release every two weeks, there's a lot of "chasing version numbers"
going on.
The problem is the convert-ly rule for the changed syntax -- if he
wrote the rule for 2.13.25 but doesn't merge until 2.13.29, then
convert-ly will have an incorrect version. This also applies to
the version number in input/regression/ files.
I'm not entirely certain why he's changing the version number in
Documentation/ files, since those should be updated by running
convert-ly on them (followed by any manual changes that are
necessary)... but here we're in uncharted and definitely
disorganized territory.
The solution might be as simple as an xargs | sed thing. Or maybe
something complicated involving git format-patch, seds, git am, branches,
etc.
Anyway, it would be good if somebody seriously looked into this.
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
