Re: How to keep different version numbers in different branches?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxxxxxx> 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>

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]