* 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 <[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
