> 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
- 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
contiguious.
-Rob Anderson
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
