ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anderson, Rob (Global Trade)" <>
Subject RE: using buildnumber effectively
Date Mon, 19 Dec 2005 21:27:45 GMT
> > >
> > > Now, suppose I branch the project to create REL_4_1.
> > > Development is still occuring in the head, but REL_4_1 is gearing 
> > > towards production.
> > >  The version number would get bumped in this branch, and not 
> > > reflected back into the head. Is there a way to do the 
> CVS merging 
> > > from the ant checkin?
> >
> > Not sure I understand what you are asking here. It is OK to release
> > REL_4_1 to production and have the main branch at say build 
> REL_5 or 
> > REL_6. When you merge the changes in REL_4_1 to main, just bump the 
> > main buildnumber again. So your production system may see REL_4, 
> > REL_4_1, and then REL_7. The sequence of buildnumbers does not 
> > necessarily need to be contiguious.
> there seems to be a break in the process, or at least some 
> manual intervention required.  say the buildnumber in the 
> head is sitting at
> 10, and i create a branch REL_1_1.   The buildnumber in this branch is
> incremented to 20 through various releases to test, and 
> finally production.  Meanwhile, the head branch never gets 
> released, and the version number is still sitting at 10.
> My question/confusion is regarding where / how the merging of 
> the version number back into the head occur?  When the next 
> project comes along and wants to go to test, they'll branch 
> from the head, and create a branch called REL_1_2.  If the 
> version number is never merged back into the head.  This 
> seems to be a manual process that must occur "every so often" 
> or rather when ever an application goes to production, the 
> version in the head needs to be evaluated.
> How do i keep the version number in the head in sync with the 
> version number in the branches?

OK. So if the build number on main is 10, then your buildnumber file
would contain the number 10 in it. When you branch, I would recommend
naming the branch based on the build number it is branched from, in this
case build 10, or perhaps REL_10 as tagged in cvs. So name the branch
REL_10 or REL_branch_10. Then on the branch reset the buildnumber to 0.
Then builds from the branch will be named REL_branch_10_1,
REL_branch_10_2, REL_branch_10_3, ect. On main, you continue with the
naming convention REL_10, REL_11, REL_12, etc. When you decide to branch
from main again, you follow the same standard. Say you wish to branch
off of REL_12, a branch named REL_branch_12 is created and builds from
that branch are called REL_branch_12_1, REL_branch_12_2,
REL_branch_12_3, etc. Bassically my recommendation is to somehow include
the branch name into the build name (or cvs tag) and use buildnumber to
increment the number on each branch. Initial setup of a branch would
include reseting the buildnumber file to 0. With the branch name in the
build name (cvs tag), you don't need to have the buildnumber is sync
between main and any branches. 

I hope this helps.

-Rob Anderson

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message