On 6/22/06, Aaron Mulder <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
