Reinhold Kainhofer <reinh...@kainhofer.com> writes: > Am Mittwoch, 14. Juli 2010, um 08:47:17 schrieb David Kastrup: >> Graham Percival <gra...@percival-music.ca> writes: >> > But if you're working on a separate branch (as is right and proper >> > for a major change), then I'm not certain how to go about it. I'm >> > looking forward to opinions. >> >> I don't see a problem here. Just merge origin/master into your work >> branch occasionally, then the patch will be relative to the current >> version. > > The problem is that many regtest files and mainly documentation files contain > \version "2.13.x" > These lines will all be out of date if a release happened while the patch was > under review.
Why? They will be "out of date" in the branch, not the release master. And once one merges with the release master, they'll be updated to the current release number as part of the merge. Am I overlooking something? > And in particular for new features, which require a particular version > (i.e. a new feature, or a changed syntax that needs a convert-ly > rule), it is essential that the version number is really the first > version where that syntax exists in the used form... If you want to work with convert-ly rules and test them in your feature branch, maybe you can use version 2.13.myfeature or similar as the release number. You'll get merge conflicts the first time around, but perhaps man git-rerere will provide a good hint how to keep the manual work required to keep updating to a minimum. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
