On Fri, 18 Jul 2008 12:46:35 +0200 Morten Brekkevold morten.brekkevold@uninett.no wrote:
This may seem a bit contrived, and it leads to having multiple heads in any series-branch, but so far I haven't thought of a more useful way of updating the VERSION file without changing it back and forth all the time.
Posting to nav-dev creates a stir in the old grey matter and causes the synapses to fire. Upon reading what I wrote, I quickly came up with an alternative and IMHO simpler approach to this.
* When the 3.4.x branch is ready for 3.4.2 release at changeset A, I will commit changeset B, which bumps the version number in the VERSION file.
* I will then update my working copy to changeset A again, tag changeset B as version 3.4.2, creating changeset C.
* I will then merge changeset B and C, but keep the contents of VERSION as it was in changeset A. In other words, I'm closing the the extra release head in the branch, and maintaining a single head for the 3.4.x branch.
I've already gone ahead and closed the release heads of series/3.4.x, and the entire series/3.4.x branch has been merged with the default branch (basically, the only changes to the default branch was the addition of the three release tags present in 3.4.x). The previously transplanted bugfixes will appear twice in the default branch, but they've merged cleanly at the tip.
Net result: Your bugfixes to released code can and should now be applied to the series/3.4.x branch, which can then be merged with default, as described in my previous posting.
If there are questions, don't hesitate to ask them here. I foresee a possible discussion here at Monday's status meeting, though ;)