maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Rosenvold <>
Subject Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Date Sun, 28 Dec 2014 18:37:47 GMT
I'll sumarize what appears to be our consensus so far.

Update to jdk 6.0 "at will", but please be sure that we're not leaving
the last 1.5 version in a regressed state.
Version number indicates minimum maven version, so a simple JDK
upgrade only mandates a minor version update.
We are also in a situation a lot of code will be migrating to 3.0.5
minimum real soon now.

Based on past experience, I know that once we start moving shared code
to 1.6, there's no turning back. So while it's certainly feasible to
our users to release "3.x" versions of our plugins with 1.5 code base,
I think this model will not sustain for any amount time. So I still
think the recommendation should be 1.6+ for the 3.x plugins, but 1.6
may also happen earlier and at RM's discretion. I really think we'd
make things a lot easier for our users by declaring the whole 3.x
range of plugins 1.6 only. But I have a feeling I'm overcomplicating
the "user" perspective since most of them couldn't care less about 1.5

I believe that sums it up. We might want to make some kind of
statement on this... ? (Does anyone really care about 1.5...?)


2014-12-27 18:28 GMT+01:00 Dennis Lundberg <>:
> Hi Kristian,
> I am +1 for any Release Manager wanting to up the minimum Java version
> to 1.6 for any of our components, on one condition: if there are any
> bugs fixed since the last release of the component, then please do a
> final Java 5 compatible release of the component before moving it to
> Java 6.
> Regarding versioning I would very much like us to use the major
> version of plugins, and other components, to indicate the minimum
> *Maven* version it requires. So I'm fine with a bump of the minor
> version for a component wishing to switch to Java 6.
> A current example the highlights both of the above is the Checkstyle
> Plugin. We will be releasing version 2.14 of the plugin as the final
> Java 5 compatible version. After that we will release version 2.15
> which will require a version of Checkstyle (the tool - not our plugin)
> that requires Java 6 making our plugin require Java 6 as well.
> We should also add an issue in JIRA for each component, specifically
> for the change in Java requirement. To make it easier for our users
> and ourselves it it also wise to add descriptions to the versions in
> JIRA. See the Checkstyle Plugin's road map for an example:
> On Wed, Dec 24, 2014 at 2:20 PM, Kristian Rosenvold
> <> wrote:
>>>Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins.
We need to upgrade to 1.6; I'm taking this to the mailing list :)
>> Last time discussed this we established a consensus to establish 3.0.5
>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
>> code base. As an example, I have been moving code to apache commons,
>> but we're basically unable to use this effort because commons is now
>> 1.6. alternately I need to backport the code in a
>> "source-level-shading", but these things are getting silly.
>> I propose the following:
>> Make the 3.x line of plugins java 1.6+ only.
>> Release all shared utilities in 1.6 versions in the 3.x version range.
>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
>> The most recent core version moves defaults to the 3.x range of plugins.
>> The parent poms migrate to 3.x range some time in the near future.
>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
>> ensure that we can still stay 1.5 compatible here.
>> Kristian
>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <>:
>>> I don't have access to push a plexus-archiver release, could you
>>> please do the honors.
>>> Also, looks like my splitting job left some work behind in terms of
>>> the parent pom.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Dennis Lundberg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message