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

[Carl Sorensen]

On 7/15/10 6:45 AM, "David Kastrup" <address@hidden> wrote:

> Graham Percival <address@hidden> writes:
> 
>> On Wed, Jul 14, 2010 at 08:56:25PM +0200, David Kastrup wrote:
>>> Carl Sorensen <address@hidden> writes:
>>> 
>>>> 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.
>>> 
>>> That sounds like the version number for a feature branch should be
>>> something like
>>> 2.14.13.feature
>>> where "x.feature" > "x".
>> 
>> We _could_ do that... VERSION has an entry for such a number,
> 
> I'd actually use an alphanumeric name corresponding to the branch.  Of
> course you'll get merge conflicts when trying to merge several such
> branches into mainline, but that's more or less the point.

Does this really work?

Suppose I develop new autobeaming for 2.13.27.5.  But the patch doesn't get
approved until 2.13.31.  That means the autobeaming code *won't* be in
2.13.28.  But if I submit patched doc files that say 2.13.27.5, people will
believe they should work in 2.13.28.  But they won't.  And there *is* no
2.13.27.5 release.

Now there's an argument that this won't cause a problem because they won't
be added to master until 2.13.31.  And somebody who comes back later can
only find that it won't work on 2.13.28 by checking through the git history.
Personally, I don't like that answer.

> 
>> I think that writing a 5-10 line shell script for easily updating
>> version numbers in a patch/commit would be much less work than
>> checking all the above, though.
> 
> The idea was to create a scheme where this more or less happens
> automatically.

I have no idea how to do that. If you have one, that would be great!

Thanks,

Carl