From: Steven Michalske <smichalske@gmail.com>
Date: Tue, 06 Apr 2010 11:29:16 GMT
Subject: Re: How to keep different version numbers in different branches?
Message-ID: <6C464226-8D13-4FB1-9017-C410011247D3@gmail.com>
In-Reply-To: <hpetj1$6af$1@dough.gmane.org>


On Apr 6, 2010, at 3:06 AM, Stephen Kelly wrote:

> Avery Pennarun wrote:
>
>> On Mon, Apr 5, 2010 at 3:22 PM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> You can even make sure it _never_ happens, by making a one-commit
>>> release branch which changes the version number for each release.  
>>> This
>>> one-commit is never merged in anything:
>>>
>>> 0.1                         0.2
>>> |                           |
>>> v                           v
>>> --o--o--o--o--o--o--o--o---o--o--o <--- master branch
>>> \                      /
>>> o--o--o--o--o--o--o--o--- ...  <--- maintainance branch
>>> \              \
>>> o <- 0.1.1     o <- 0.1.2
>>>
>>> Here, the maintainance branch never changes the version number in
>>> README & friends.
>>
>> This works too.  In fact, I even do it on one of my projects.
>> However, I find it a little annoying, because then I don't know which
>> version to tag: the pre-number-changed version, or the
>> post-number-changed version.
>>
>> The latter sounds like the obvious answer, but if I do that, then  
>> "git
>> describe" never says anything useful on my master branch.  But if I  
>> do
>> the former instead, then the tag doesn't accurately reflect the
>> version I *actually* released.
>>
>> I've never found an adequate solution to this problem, other than not
>> including the version number in the repo at all.
>
> Hi all,
>
> Thanks for the pointers. I considered the above solution too, but
> disregarded it for the same reason.
>
> I also considered the git describe solution, but disregarded it  
> because in
> CMake I need to know each component of the version separately
> (Grantlee_VERSION_MAJOR, Grantlee_VERSION_MINOR and  
> Grantlee_VERSION_PATCH).
> I could split it on '.', but I think the better solution is to just  
> put the
> version into the CMake files and deal with the conflict in that one  
> place as
> it comes up. I can always switch in the future anyway if using  
> describe
> makes more sense.
>

You might want to look into a filter that edits the cmake file.

smudge in the version information, and clean it out.

See  keyword expansion <http://progit.org/book/ch7-2.html>