Date
1 - 1 of 1
Q on preferred version bumping practice
Larry Gritz
As discussed in the last TSC meeting, I'm working on documenting our release practices, and I have a question about how people prefer to have the timing of version number changes in the trunk.
We release a tagged patch to the supported release branch monthly (more or less). But in between these tag+release events, we cherry-pick fixes into the branch that will get tagged for the next month's release. In other words, we have a history that looks like:
tagged 1.2.3 --> change A --> change B --> change C --> next tagged release
Here is the question. WHEN should we change CMakeLists.txt to bump the release number of this in-progress development branch to 1.2.4?
1. Bump the number at (A), so a dev build that includes ANY changes after the 1.2.3 release advertises itself as if it were the next version.
2. Bump the number at (C), the very last thing we do before tagging the next release, so that no build advertises itself as 1.2.4 until it's really a 1.2.4 release (or later).
3. It doesn't matter, any time between the releases is fine.
I've seen projects that operate both ways, and I think either is justifiable. I tend to do the first one, but I don't have any strong religious feelings about it. Since I'm writing docs for this process anyway, I thought I'd take this opportunity to see if people like that or if you would prefer the alternative.
--
Larry Gritz
lg@...
We release a tagged patch to the supported release branch monthly (more or less). But in between these tag+release events, we cherry-pick fixes into the branch that will get tagged for the next month's release. In other words, we have a history that looks like:
tagged 1.2.3 --> change A --> change B --> change C --> next tagged release
Here is the question. WHEN should we change CMakeLists.txt to bump the release number of this in-progress development branch to 1.2.4?
1. Bump the number at (A), so a dev build that includes ANY changes after the 1.2.3 release advertises itself as if it were the next version.
2. Bump the number at (C), the very last thing we do before tagging the next release, so that no build advertises itself as 1.2.4 until it's really a 1.2.4 release (or later).
3. It doesn't matter, any time between the releases is fine.
I've seen projects that operate both ways, and I think either is justifiable. I tend to do the first one, but I don't have any strong religious feelings about it. Since I'm writing docs for this process anyway, I thought I'd take this opportunity to see if people like that or if you would prefer the alternative.
--
Larry Gritz
lg@...