Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold
<kristian.rosenv...@gmail.com>:
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.
When talking about migrating plugins, we should make the plugins 3.0(.x)
compatible, so we should use migrate to 3.0 (the lowest) and not 3.0.5
(the latest).
Most important: for the plugins it doesn't matter; I'm not aware of any
code where it makes any difference.
This should give us enough space to remove all M2 hacks with reflections,
etc.
And this makes it a lot easier to communicate with the community by just
saying: maven-plugins 3.x are compatible with all Maven3 distributions.
Robert
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
anyway.
I believe that sums it up. We might want to make some kind of
statement on this... ? (Does anyone really care about 1.5...?)
Kristian
2014-12-27 18:28 GMT+01:00 Dennis Lundberg <denn...@apache.org>:
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:
http://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
On Wed, Dec 24, 2014 at 2:20 PM, Kristian Rosenvold
<krosenv...@apache.org> 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 <bimargul...@gmail.com>:
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Dennis Lundberg
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
