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

[Carl Sorensen]

On 7/14/10 11:12 AM, "Joe Neeman" <address@hidden> wrote:

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

The version number of a build from the current git will be higher than the
last release version.  This particular patch uses changes in .cc code, so it
needs to be rebuilt, and hence will always be a version ahead of the current
git.

If you want to do make check on a binary that's older than current git, you
can always do so by checking out input/regression from the released branch.

I think it is crucial to track these versions manually for at least
convertrules.py and Documentation/snippets/new/*.ly.  When makelsr.py is
run, it adds a comment that indicates the first version for which the
snippet worked, which is the version in D/s/n/.

Also, as far as regression tests are concerned, if we don't have the right
version in the regtest, then the regtest will be broken.  That is, if the
regtest uses syntax that is introduced in 2.13.29, but I used 2.13.27
because that was the current devel release when I started the patch, it
won't run on 2.13.27, so the file is wrong.

If we're going to have versions in the regtests, we better make sure the
regtest runs on the version that's in the file, IMO.

Thanks,

Carl