On 12/19/05, Anderson, Rob (Global Trade) <[EMAIL PROTECTED]> wrote:
> > 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.
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?
>
> -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]
