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 19:46:40 GMT
> We're looking to attach a buildnumber to our current build process.
> Only test and production builds will need to have the 
> buildnumber incremented.  

It's OK to increment the buildnumber for development builds too.

> I've noticed the buildnumber task 
> in ant and am curious how others are using this task?

I have used the buildnumber task to generate a unique identifier that I
will tag the repository with. Typically, I will do a cvs rtag
${PROJECTNAME}_${BRANCH}_${build.number}. When a build is deployed to
production I will manually rtag the repository with an additional tag to
reflect the fact that that build was deployed to production.

> Working from the head, it would seem fairly simple:
> - update the sources from cvs,
> - bump the version number,
> - build  the archive (war, jar, ear, whatever),
> - checkin the updated buildnumber file to cvs.   golden.

You could add cvs rtag to the end of this.

I like a slight variation of this:

- update the buildnumber file from cvs
- bump the version number
- checkin the update buildnumber file
- rtag the repository with ${PROJECTNAME}_${BRANCH}_${build.number}
- cvs update -r ${PROJECTNAME}_${BRANCH}_${build.number} to get the
- build

This process adds the rtag so that the repository tagged. The reason for
doing an rtag and then cvs update -r in that order is to eliminate the
possibility of a developer checking in a file between the time you run
cvs update and cvs rtag.

> 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

-Rob Anderson

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

View raw message