maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Date Tue, 03 Jan 2012 23:12:18 GMT
also part of the problem in this specific case is that it is tricky to test
the release plugin... i may look into refactoring the current tests to be
based off of mrm-maven-plugin, as that should open up additional test
paths. further i may add some multi-maven version testing so that the tests
run against a couple of maven versions rather than just the invoking one.

but for now we just have to live with the bug by either keeping to version
2.2.1 (of one of either maven or the release plugin) or wait until 3.0.5,
or beat up olamy to backport the (fairly low risk) fix

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 3 Jan 2012 22:51, "Brett Porter" <brett@apache.org> wrote:

>
> On 04/01/2012, at 9:04 AM, Ansgar Konermann wrote:
>
> > Am 03.01.2012 22:12, schrieb Benson Margulies:
> >> On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt <mark@talios.com> wrote:
> >>> Surely something as egregious as allowing releases to break should
> block
> >>> 3.0.4 from being released tho.  As someone who uses GPG in that manner
> for
> >>> some of his releases I'd certainly want 3.0.4 to be able to release...
> >>
> >> I disagree. There's no law requiring people to use 2.2.2 of the plugin.
> >
> >
> > Hi,
> >
> > that's is an interesting point. No offense here, but what *is* the law
> > w.r.t a "Maven Release"? I'm not that deep into Apache and Maven
> > processes, but from what I could learn from public sources so far, I
> > believe this is not clear altogether, and it might help to discuss this
> > and make up our mind regarding such a "law" (i. e. release policy) to
> > have a guideline for the future.
> >
> > Being a bit heretical: is it Maven's policy to release only Maven and
> > wish the user luck to find out which versions of the core plugins work
> > well with which version of Maven?
> >
> > Or can the average user expect to be reasonably safe if using the latest
> > release of Maven with the latest release of any core plugin?
> >
> > From a user perspective, I perceive Maven as "the Maven application plus
> > its core plugins" - they are basically one system. Agreed, it has a
> > highly modular architecture, and a lot of these modules (= plugins) have
> > decoupled release cycles, nevertheless it's IMHO hard to sell to the
> > average user that the newest bugfix release of Maven with the newest
> > bugfix release of the release plugin has *more* bugs than the slightly
> > outdated one.
>
> We have a number of "core plugins" with versions set in the parent POM
> with each release. We use an unsophisticated metric to decide what to use:
> - been out for a while without reports of major projects
> - someone was motivated to update it
>
> They'll generally be very stable but may lag the latest releases - but you
> should consider those will all work well out of the box.
>
> It's on the plugin authors to test their plugins with different released
> versions of Maven and report on compatibility.
>
> For new Maven releases, we rely on the user community testing to identify
> any regressions with various different versions of plugins, so there's no
> blessed versions. If you're conservative, you might use the same policy we
> use for the core plugins, though I'd speculate the people inclined to test
> the release probably tend to test with close to recent versions of plugins.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message