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

[Joe Neeman]

On Wed, Jul 14, 2010 at 7:09 AM, Carl Sorensen <address@hidden> wrote:

On 7/14/10 4:21 AM, "David Kastrup" <address@hidden> wrote:

> 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?

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.

Is it really crucial to track this manually? The git history will already tell us when a regression test was added. Plus, we lose this manual history whenever convert-ly is run (even for changes that are orthogonal to what the regression test is checking) and it makes "make check" slightly less convenient if you have regression tests whose version number is higher than the last release version.

Cheers,
Joe