cool - 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 4 Jan 2012 20:58, "Olivier Lamy" <ol...@apache.org> wrote: > Hello, > it added and fix merged in RC branch. > > On irc, Robert remember me the upgrade of site plugin version for site > lifecycle (was mentioned in a previous RC thread) > I will add that too. > As it's IMHO very low risk as mvn3.x users already add site plugin > version in their pom to get site plugin working. > > 2012/1/4 Stephen Connolly <stephen.alan.conno...@gmail.com>: > > i have the fix written and on the 3.0.5 trunk... with some unit tests > also. > > > > been trying to write a core it, but so far all my attempts have seemed > too > > heavy to add to the test suite. > > > > - 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 4 Jan 2012 08:34, "Olivier Lamy" <ol...@apache.org> wrote: > > > >> 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 > >> > >> > > > > -- > 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 > >
