+100 .. I totally agree. RIP Maven 2.x
EOL Maven 3.0.x very soon And more importantly... update the website and clearly document that state. manfred Stephen Connolly wrote on 29.09.2014 12:35: > well one thing I would like us to do better is communicate exactly which > release lines of Maven we are actively maintaining and what we mean by such > active maintenance. > > My personal view is > > * if there has been no commit to a release line for > 1 year then it is not > in active maintenance > > * if there has been no commit to a release line for > 2 years (and > consequently no release) then we should consider that line potentially > dead... releasing core is tricky enough, so if we have not cut a release of > an older line for more than 2 years then the hurdle to actually cut a > release may be sufficiently high as to prevent any releases. > > If we take that criteria into account, 3.0.5 is nearing the end of life. > 3.1.1 is probably not being actively maintained. > > So I would be looking to mark the 3.0.x line EOL either now or in 5 months > > I would be looking to say 3.1.x is "security fixes only" next month > > Consequently I would be happy to say that core plugins can pick 3.2.x as > their baseline and be done with it... if people feel strongly against > that... well, if they are committers then I will vote on their releases > from a "stable" branch... if they are not committers, then I will apply > their patches and canvas to make them committers... > > For the project's sake, in my view, we have to start clearing out the > cruft... if that means JDK6 as the minimum for everything... fine! if that > means Maven 3.2.1 as the minimum for everything, even better... > > Users will be stubborn and use the older versions as long as they can... > but it is increasingly difficult for use - as developers - to develop while > maintaining support for those older jdks and the range of maven cores. If > we can simplify then we should be able to progress faster... > > Of course the only rider is that I seem perpetually stuck in side projects > and work projects and never seem to get as much time as i would like to > work on Maven... so I'm not going to force anything.... ultimately it's the > committers that drive this project... I'm just putting my voice out there > for the active committers to take heed of or ignore as they see fit! > > On 29 September 2014 20:21, Dennis Lundberg <[email protected]> wrote: > >> On Sun, Sep 28, 2014 at 5:46 PM, Stephen Connolly >> <[email protected]> wrote: >> > Well why I recall we said last time was that we'd only support the jdk >> > supported by the supported versions of maven >> > >> > So *if* one of the core plugins chooses - for technical reasons (such as >> > try with resources or the diamond operator making the code nicer) to bump >> > its dependency to maven 4.0 then that's fine >> > >> > Right now if a plugin has a technical need to force jdk 1.6 it can just >> do >> > that... For users it is cleaner to push that by upping the minimum maven >> > version to 3.2.1 as that guarantees jdk 1.6 minimum. >> > >> > We have not spelled out how we support plugins. The core policy we said >> is >> > a bit wooly but right now we have three lines all less than two years >> > old... My point of view is that we should say: >> > >> > 3.0.x is security fixes only >> > 3.1.x is security fixes only (unless a specific RM steps up... This is >> the >> > call for a committer who wants jdk 1.5 support retained to step up) >> > 3.2.x is active >> >> Regardless of how this discussion and any following vote threads goes, >> we should document the Java requirements for Maven and its various >> components somewhere on our site. There should also be a link to that >> page from the front page called "Technical requirement" or something >> like it. If we can say Java 6 for everything that'll make things easy >> to start with. After that we can add an exceptions-from-the-rule >> section to the page, when some component needs to use a newer version >> of Java for some technical reason. >> >> > >> > So if the plugin developers find their life simplified by restricting to >> > only modern fully supported versions of maven, then let's up them to >> 3.2.x >> > APIs and req jdk 1.6... If there are Committers with needs to support jdk >> > 1.5 we will not prevent them continuing but by and large what I tebd to >> see >> > is a lot of noise that prevents progress and not a lot of stepping up. >> > >> > So if you want a vote that says "unless plugin maintainers feel strongly >> > otherwise, the default is that all new plugin releases should require >> maven >> > 3.2.x and jdk 1.6 as a minimum" then you have my +1 >> > >> > Oracle are being aggressive with EOL of jdks so IIUC by the time we >> > actually cut 4.0 it may be jdk 8 and 9 as the only supported versions... >> > Yeeehaw!!! >> > >> > (FYI jenkins is currently considering jdk 8 as a minimum.... I'd love if >> we >> > could jump there too) >> > >> > On Saturday, 27 September 2014, Kristian Rosenvold < >> > [email protected]> wrote: >> > >> >> Yeah Karl, I think you're right :) Things aren't always that easy so >> >> we tend to err in favor of being conservative, which I think is ok. >> >> Personally I think all java versions < 1.8 are a drag right now. So I >> >> think we call a straight vote for 1.6 for everything. Although not >> >> very ambitious, it moves us one step forward. In another 6 months we >> >> do 1 more step forwards :) >> >> >> >> We'll keep this thread open until monday and then call a vote. >> >> >> >> Kristian >> >> >> >> >> >> 2014-09-27 20:56 GMT+02:00 Karl Heinz Marbaise <[email protected] >> >> <java script:;>>: >> >> > Hi Kristian, >> >> > >> >> >> Karl; I think you are mixing concerns somewhat -making things a >> little >> >> >> >> >> >> more complex than they need to be. >> >> > >> >> > >> >> > I think it is not that simple... >> >> > >> >> >> >> >> >> I would propose that most people using 2.2.1 are not doing so due to >> >> >> the java version, >> >> > >> >> >> but simply because they have not ported their build >> >> >> >> >> >> to 3.X due to a bag of different constraints, java version being only >> >> >> one of them. >> >> > >> >> > >> >> > some people do and some don't...but this is an other story.... >> >> > >> >> >> >> >> >> So most users would be able to run 2.2.1 with jdk 1.6. And they can >> >> >> still run 2.2.1 with jdk 1.5, they'll just be missing >> >> >> the upgrades. >> >> > >> >> > >> >> > I'm with you..... >> >> > >> >> >> This is the "cost" of running old software, and the >> >> >> >> >> >> industry as a whole is making running legacy versions >> >> >> cumbersome/costly. >> >> > >> >> > >> >> > really true...But the problem is that migration takes time/money...... >> >> > >> >> >> >> >> >> But I think coupling java version -> maven version like you're doing >> >> >> is basically flawed; for most users this is not about java versions. >> >> > >> >> > >> >> > It's a point of view...as i mentioned...consistency... >> >> > >> >> > You are right that i'm coupling this...if it's flawed...it depends... >> >> > >> >> > The java versions are the most cases where an update takes much longer >> >> than >> >> > you think...i have customers which are running on Java 1.5 and Java >> 1.6 >> >> (IBM >> >> > based as Anders...1.6 +1...)... >> >> > >> >> > I have written down my thoughts....but of course we can go a different >> >> > way...i just wanted to give my thought and to reconsider things like >> >> > this...for a further decision... >> >> > >> >> > 1.6 might be a good alternative...to go with... >> >> > >> >> > >> >> > >> >> >> >> >> >> Kristian >> >> >> >> >> >> >> >> >> 2014-09-27 20:01 GMT+02:00 Karl Heinz Marbaise <[email protected] >> >> <java script:;>>: >> >> >>> >> >> >>> Hi Kristian, >> >> >>> >> >> >>> On 9/27/14 7:23 PM, Kristian Rosenvold wrote: >> >> >>>> >> >> >>>> >> >> >>>> We moved core to 1.6 some time ago. >> >> >>> >> >> >>> >> >> >>> >> >> >>> As far as i know starting with Maven 3.2.1...was the first one... >> >> >>> >> >> >>>> >> >> >>>> >> >> >>>> Time to move everything else as well ? >> >> >>> >> >> >>> >> >> >>> >> >> >>> We have at the moment a large number of plugins which have minimum >> >> Maven >> >> >>> 2.2.1 (JDK 1.5)...and few are currently at Maven 2.0.6 (that's only >> >> for >> >> >>> a >> >> >>> limited amount of time) >> >> >>> >> >> >>> The next round should be to lift up to Maven 3.0.5 at minimum which >> >> >>> implies >> >> >>> to left Maven 2 finally behind..... >> >> >>> >> >> >>> Making it visible to people by using 3.X versions for the plugins or >> >> >>> something similar... >> >> >>> >> >> >>> ...afterwards i see the next round to lift up to Maven 3.1.1... >> >> >>> and after that i see the next lift up to Maven 3.2.1 which implies >> Java >> >> >>> 1.6...and so on.... >> >> >>> >> >> >>> It's a longer way...which takes time... >> >> >>> >> >> >>>> >> >> >>>> Kristian (Who's ready to say "1.7" but we stop by 1.6 first :) >> >> >>>> >> >> >>> >> >> >>> If we go the above path it's of course longer but more consistence >> from >> >> >>> the >> >> >>> user point of view...using Maven 3.0.5 which works with Java 1.5 >> ...and >> >> >>> the >> >> >>> plugins as well...etc... >> >> >>> >> >> >>> Of course from the technical point of view it's not that good ;-(... >> >> >>> >> >> >>> So from my site i would vote with +0 ... >> >> >>> >> >> > >> >> > Kind regards >> >> > Karl-Heinz Marbaise >> >> > >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> <java script:;> >> >> > For additional commands, e-mail: [email protected] >> >> <java script:;> >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] <java script:;> >> >> For additional commands, e-mail: [email protected] >> <java script:;> >> >> >> >> >> > >> > -- >> > Sent from my phone >> >> >> >> -- >> Dennis Lundberg >> >> --------------------------------------------------------------------- >> 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]
