activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Streamlining the ActiveMQ release process
Date Thu, 27 Jul 2006 08:27:34 GMT
Incidentally I've struggled a bit with the release plugin in the past;
have found it a little temperamental. (I ended up not using it when I
released xbean as I just couldn't get it to work after following the
instructions to the letter). The bits I like though are all that
switching of poms, tagging and switching poms back to the snapshot
etc. (Checking for SNAPSHOTs is good too).

I wonder if there's some way of patching the release plugin to work
with our style of release processes - where the release is created,
voted on and then if approved then actually done. The main problem
seems to be we need to produce the release on a 'staging area' (such
as our home directory), then if it gets voted in, move it to the
actual m1/m2 repositories (assuming one day we get a m2 repository we
can actually use at apache for incubating projects :-).

I guess the current release plugin prepare is fine - its more the
perform that we need to split into two parts.

Assuming we found the release plugin to be reliable and work for us,
we could do a release:prepare, then take the properties file and use
it to perform a release:perform-sample which would create a full
release but deploy it to our home directories at Apache rather than
the real repos. Then after the vote, we do a release:perform which
should do exactly the same thing but deploy in the real location?

I'd have a warm fuzzier feeling if we just moved the artifacts across
though, you never know some gremlin could occur between
release:perform-sample and release:perform.

So maybe we make release:perform go to our home directories and we
have some maven plugin to move a release in our home directory to the
real repos? e.g. after a release is performed we do a

  mvn release:approve

which moves from the home directory to the official m1/m2 repos?

I guess the use of the release plugin could be completely optional -
we could just do

mvn deploy

which would go to our home directories for non-snapshots; then we have
some kinda 'approve' plugin which moves the release in our home
directory to the m1/m2 repo?


On 7/26/06, Guillaume Nodet <gnodet@gmail.com> wrote:
> True.
> So we must either:
>    * change our release process to the maven practice, i.e. vote on
> snapshots and then release
>    * find a nice way to release things and document it.
>
> Also note that our release process is somehow problematic.
> The way I did in ServiceMix and Xbean was to deploy the release to a private
> remote repository at Apache.
> But when the release is approved, you have to put the content of the repo in
> the public Apache repositories
> (at least for XBean, because ServiceMix and ActiveMQ are still in
> incubation).
> But if you just copy things, some metadata on the repository are lost :(
>
> From what i heard, maven 2.1 should handle such a release process better,
> but i'm not sure how.
>
> Cheers,
> Guillaume Nodet
>
>
>
> On 7/26/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> >
> > I actually think the maven 2 release plugin is a bit of pain.  It's not
> > built to follow our release process where we put up release candidates,
> > hold
> > a vote, then deploy the release binaries.  It also handles the branching
> > and
> > tagging very differently.
> >
> > On 7/26/06, James Strachan <james.strachan@gmail.com> wrote:
> > >
> > > Sounds cool with me. I guess once we get to 4.1 we can use the maven 2
> > > release plugin to make this kinda stuff easier
> > >
> > > On 7/26/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> > > > Hi,
> > > >
> > > > I just recently put up a ActiveMQ 4.0.2 release candidate for vote so
> > > while
> > > > it's fresh on my mind I'd like to see if anybody minds if I make a
> > small
> > > > tweak to the way we label our snapshot versions.  I'd like to either
> > > change
> > > > it to 4.0-SNAPSHOT or even 4.0.x-SNAPSHOT.
> > > >
> > > > The driver behind this change is that on the 4.0 branch, every time we
> > > do a
> > > > release (for example this 4.0.2 release), we have to remember to
> > > increment
> > > > the version on the branch on all the poms.  It's easy to forget to
> > > change
> > > > this and I don't see much value in changing the pom after every
> > release.
> > > >
> > > > --
> > > > Regards,
> > > > Hiram
> > > >
> > > > Blog: http://hiramchirino.com
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > James
> > > -------
> > > http://radio.weblogs.com/0112098/
> > >
> >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
> >
>
>


-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message