On Sun, Dec 28, 2014 at 9:04 PM, Robert Scholte <[email protected]> wrote:
> Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold < > [email protected]>: > > 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. > Very much +1 on this. The discussion around requiring 3.0.5 was to force the users to update to a Maven version which didn't have a specific bug or similar. I personally don't think we should use the minimum Maven version for that but strictly go for technical reasons (such as API) and in that case v 3.0 should be enough. /Anders > > 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 <[email protected]>: >> >>> 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 >>> <[email protected]> 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 <[email protected]>: >>>> >>>>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> -- >>> 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] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
