Maybe this should be a new thread, but once you increment your build number, what is the best practice to show this build/release in your applications?
For instance, I would want to see the build/release number on the footer of my website. -----Original Message----- From: Mark Lybarger [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 20, 2005 5:53 AM To: Ant Users List Subject: Re: using buildnumber effectively that's definately a great idea. how do i get the branch name of cvs from within ant? basically, which cvs branch is this? On 12/19/05, Anderson, Rob (Global Trade) <[EMAIL PROTECTED]> wrote: > > > > > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
