On 7/14/10 4:21 AM, "David Kastrup" <d...@gnu.org> wrote:
> 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?
Yes. The versions that need to be put in the files need to be the version
at which the new syntax is introduced, not the current version.
It's not a merge conflict issue. It's an issue of tracking the version at
which a new syntax is introduced.
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
