geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
Date Thu, 22 Jun 2006 01:20:24 GMT
According to the maven guys, the release process is:
  * deploy snapshot
  * vote on snapshot
  * build and deploy a release

Currently the m2 release process (if you use the release plugin is):
  * change all versions in poms and commit
  * create a tag
  * release and deploy from tag
  * revert to snapshots and commit
AFAIK, this can be done from trunk or branch.

The only problem i see is that you have currently no way to:
  * deploy to a private repo without changing the pom
  * promote a build to a release, so once a build has been voted,
     the release must be rebuild and redeployed (the binaries are different)

Cheers,
Guillaume Nodet



On 6/22/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
>
> Hi Jason,
>
> The problem is that it can take weeks to do a geronimo release since
> stuff like CTS testing is involved.  So the release work (putting the
> finishing touches) needs to be done in a branch so that work can
> continue on the next release.
>
> Perhaps m2 has a way of dealing with those issues along with
> re-cutting releases and such.  But since I have not done a m2 based
> release yet, I'm not sure what's involved.  Could you clarify it a bit
> for me?
>
> On 6/21/06, Jason Dillon <jason@planet57.com> wrote:
> > > Hi Jason,
> > >
> > > I agree that we should avoid branching.  But I do agree with the 1.1.1
> > > branch.  It's a dead-end branch in that it's only used to prepare he
> > > release.  Applying last minute fixes and changing version numbers.
> > > Since it's a dead-end branch, once the release if approved
> > > moving/deleting it makes sense.
> >
> > I would make those changes on the 1.1 branch (or trunk if we were
> > using that codebase), then release and let Maven make the tag and
> > then update the versions to the next SNAP.
> >
> > When moving to m2 we really need to follow the m2 release system,
> > else the number of changes to poms is going to get out of control and
> > will be very error prone.
> >
> > --jason
> >
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>

Mime
View raw message