2012/1/4 Benson Margulies <bimargul...@gmail.com>: > On Tue, Jan 3, 2012 at 6:12 PM, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: >> 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 > > Good luck there. His wife just presented him with another offspring, a > trifle ahead of schedule.
Usually, this doesn't prevent to hack :-) Today or tomorrow, I will try to write a core it test for this issue and have a look at the changes to fix that. > >> >> - 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" <br...@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 <m...@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 >>> br...@apache.org >>> http://brettporter.wordpress.com/ >>> http://au.linkedin.com/in/brettporter >>> http://twitter.com/brettporter >>> >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
