geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.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 14:16:36 GMT
On 6/22/06, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
> +1 To Jason's comments with Hiram's comments...
>
> I think we should do all development of 1.1.x in branches/1.1 (with
> version 1.1.N-SNAPSHOT).  But at the time we code freeze for a
> release, I think we should svn copy branches/1.1 to branches/1.1.N and
> finalize the version numbers there (to version 1.1.N) and make any
> last-minute tweaks there and update branches/1.1 to version number
> 1.1.(N+1)-SNAPSHOT.  When we have a candidate for the release, then we
> can svn copy branches/1.1.N to tags/1.1.N and build the release from
> the tag.

BTW: I don't think there is any harm in doing the release from the
branch if the branch is copied to the tag since the source code should
be identical between them.  I think we should perhaps avoid creating
the the tag until we KNOW that the binary is approved.

>
> Thanks,
>    Aaron
>
> On 6/21/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
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message