Re: Can't get a patch through because of weekly development releases.

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> Am Mittwoch, 14. Juli 2010, um 08:47:17 schrieb David Kastrup:
>> Graham Percival <address@hidden> 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