Is the release plugin intended to be run manually?

["KARR, DAVID" <dk...@att.com>]

I noticed a comment in http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not using the release plugin because it checks in POMs after updating versions, which isn't suited to a continuous delivery pipeline.  Is the release plugin intended to be run manually, and not part of an automated build?

The documentation for the plugin doesn't really address this question.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Is the release plugin intended to be run manually?

[Brian Topping <to...@codehaus.org>]

On Sep 11, 2012, at 7:02 PM, "KARR, DAVID" <dk...@att.com> wrote:

> I noticed a comment in http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not using the release plugin because it checks in POMs after updating versions, which isn't suited to a continuous delivery pipeline.  Is the release plugin intended to be run manually, and not part of an automated build?
> 

> The documentation for the plugin doesn't really address this question.

The deploy phase is typically used for CI.  See http://www.sonatype.com/books/mvnref-book/reference/lifecycle-sect-common-goals.html#lifecycle-sect-deploy-phase.  

Release is different, it's what you do when you want to update the version numbers and have a concrete reproducible point in the source tree.  Most orgs do this manually because of the care that is required, but I've set it up as a pushbutton on CI servers for folks that don't have a lot at stake.

They are both supported by plugins with those names, but they are very distinct in the project lifecycle.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Is the release plugin intended to be run manually?

[Wayne Fay <wa...@gmail.com>]

> I noticed a comment in ... about not using the release plugin because it
> checks in POMs after updating versions, which isn't suited to a continuous
> delivery pipeline.  Is the release plugin intended to be run manually, and not
> part of an automated build?

The plugin can be used in an automated fashion (check out batch mode)
or manually. I expect there are large numbers of users for both styles
of use.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Is the release plugin intended to be run manually?

[Stephen Connolly <st...@gmail.com>]

I have used maven for CD on some projects... But I find CD to be less
useful than a simple release often approach.

The key take home of CD for me is that you always should be able to release
the master branch. That no long lived branches should exist is secondary.
Actually pushing releases every commit/hour/day/week is less useful IMHO.

On Tuesday, 11 September 2012, Ansgar Konermann wrote:

> What will happen to maven if we moderate discussions touching continuous
> delivery aggressively?
>
> Those who do want to use CD, which tools will they use? Where can they
> learn how to use maven for CD?
>
> How can maven developers learn how maven could evolve to facilitate maven
> usage in CD setups?
>
> What means are in place to allow this kind if exchange?
>
> If there is only little chatter in the maven community regarding CD, would
> you choose maven when designing a fresh CD pipeline?
>  Am 11.09.2012 22:13 schrieb "Benson Margulies" <bimargulies@gmail.com<javascript:;>
> >:
>
> > Every time that 'continuous delivery' shows up on this mailing list,
> > we end up with 10,000 lines of opinionated email about this
> > extraordinarily controversial topic.
> >
> > I respectfully plead with all of you to use this mailing list for
> > practical, answerable, questions about the behavior of Maven, and find
> > some other venue to talk about CD.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org<javascript:;>
> > For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> >
> >
>

Re: Is the release plugin intended to be run manually?

[Ansgar Konermann <an...@googlemail.com>]

What will happen to maven if we moderate discussions touching continuous
delivery aggressively?

Those who do want to use CD, which tools will they use? Where can they
learn how to use maven for CD?

How can maven developers learn how maven could evolve to facilitate maven
usage in CD setups?

What means are in place to allow this kind if exchange?

If there is only little chatter in the maven community regarding CD, would
you choose maven when designing a fresh CD pipeline?
 Am 11.09.2012 22:13 schrieb "Benson Margulies" <bi...@gmail.com>:

> Every time that 'continuous delivery' shows up on this mailing list,
> we end up with 10,000 lines of opinionated email about this
> extraordinarily controversial topic.
>
> I respectfully plead with all of you to use this mailing list for
> practical, answerable, questions about the behavior of Maven, and find
> some other venue to talk about CD.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Is the release plugin intended to be run manually?

[Benson Margulies <bi...@gmail.com>]

Every time that 'continuous delivery' shows up on this mailing list,
we end up with 10,000 lines of opinionated email about this
extraordinarily controversial topic.

I respectfully plead with all of you to use this mailing list for
practical, answerable, questions about the behavior of Maven, and find
some other venue to talk about CD.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Is the release plugin intended to be run manually?

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

Continuous Delivery challenges that belief.

I am not convinced either actually.  Particular for very large enterprise builds where final artifacts are in the order of gigs in size. Imagine a project that large with dozen of developers committing to the code base many times a day and releasing each and every one of those commits?  Now imagine deciding which of the released builds to keep and removing the binaries you don't want to avoid confusion. That's a lot of work.

CD is a great idea.  From a purely maven perspective, however, I don't think it is quite ready yet to adopt a CD model.  I think some work needs to be done to bridge the differences between a SNAPSHOT build and a release build to a point where they are effectively the same and you no longer have two kinds of builds. Of course, the challenge is to retain the advantages of both and that is a challenge I don't think is as easy as it may at first sound.

> -----Original Message-----
> From: Lyons, Roy [mailto:Roy.Lyons@cmegroup.com]
> Sent: Tuesday, September 11, 2012 12:43 PM
> To: Maven Users List
> Subject: RE: Is the release plugin intended to be run manually?
> 
> My recommendation is to keep your release builds manual or cron based.
> You can add a "release:prepare -DdryRun=true -B" to your CI if you want
> to make sure that a future release build will work properly.  The main
> issue with using source change detection in a CI job and running the
> release plugin is that you will end up in an infinite loop, and your
> version will be "over 9000" by morning.
> 
> My personal belief is that release builds should not be happening every
> hour or every few minutes.  That's what snapshots are for.  Whether you
> are agile or waterfall, the goal is to always produce a release build
> on code that has working features (or so developers claim anyhow).
> Basically, that's a piece which is best left to either human eyes, or
> to a set of automated testing scripts which could also kick off a
> release build upon success.  Perhaps I take it a little too seriously -
> - but that's my job as an SCM engineer :)
> 
> Thanks,
> 
> Roy
> 
> -----Original Message-----
> From: KARR, DAVID [mailto:dk068x@att.com]
> Sent: Tuesday, September 11, 2012 11:02 AM
> To: Maven Users List
> Subject: Is the release plugin intended to be run manually?
> 
> I noticed a comment in
> http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html
> about not using the release plugin because it checks in POMs after
> updating versions, which isn't suited to a continuous delivery
> pipeline.  Is the release plugin intended to be run manually, and not
> part of an automated build?
> 
> The documentation for the plugin doesn't really address this question.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Is the release plugin intended to be run manually?

["Lyons, Roy" <Ro...@cmegroup.com>]

My recommendation is to keep your release builds manual or cron based.  You can add a "release:prepare -DdryRun=true -B" to your CI if you want to make sure that a future release build will work properly.  The main issue with using source change detection in a CI job and running the release plugin is that you will end up in an infinite loop, and your version will be "over 9000" by morning.

My personal belief is that release builds should not be happening every hour or every few minutes.  That's what snapshots are for.  Whether you are agile or waterfall, the goal is to always produce a release build on code that has working features (or so developers claim anyhow).  Basically, that's a piece which is best left to either human eyes, or to a set of automated testing scripts which could also kick off a release build upon success.  Perhaps I take it a little too seriously -- but that's my job as an SCM engineer :) 

Thanks,

Roy

-----Original Message-----
From: KARR, DAVID [mailto:dk068x@att.com] 
Sent: Tuesday, September 11, 2012 11:02 AM
To: Maven Users List
Subject: Is the release plugin intended to be run manually?

I noticed a comment in http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not using the release plugin because it checks in POMs after updating versions, which isn't suited to a continuous delivery pipeline.  Is the release plugin intended to be run manually, and not part of an automated build?

The documentation for the plugin doesn't really address this question.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Is the release plugin intended to be run manually?

[Graham Leggett <mi...@sharp.fm>]

On 11 Sep 2012, at 6:02 PM, KARR, DAVID wrote:

> I noticed a comment in http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not using the release plugin because it checks in POMs after updating versions, which isn't suited to a continuous delivery pipeline.  Is the release plugin intended to be run manually, and not part of an automated build?
> 
> The documentation for the plugin doesn't really address this question.

In theory, any plugin target can be executed as part of an automated build, the release plugin is no different.

Regards,
Graham
--