On Tue, Jan 3, 2012 at 6:12 PM, Stephen Connolly <[email protected]> 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. > > - 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" <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://brettporter.wordpress.com/ >> http://au.linkedin.com/in/brettporter >> http://twitter.com/brettporter >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
