I think that Michael might be over-reading my intentions. I am not trying to start a short-term avalanche of moving components to require 3.0.5. My idea is:
1. We release parents that set up the 3.0.5 dependencies. Call that version Q. 2. Any maintainer who feels inclined to release a 2.2.x-compatible component or plugin is welcome to continue to use parent Q-1. 3. Any maintainer who feels inclined to move a component to the new regime changes the parent version to Q. As far as I am concerned, it might take _years_ before everything under the auspices of this project moves to require 3. On Sun, Feb 23, 2014 at 3:38 PM, Michael Osipov <micha...@apache.org> wrote: > Am 2014-02-23 21:20, schrieb Stephen Connolly: > >> On Sunday, 23 February 2014, Michael Osipov <micha...@apache.org> wrote: >> >>> Am 2014-02-23 19:06, schrieb Benson Margulies: >>> >>>> I propose to make releases of our parent stack that are suitable for >>>> components and plugins that are making the leap to Java 1.6 and Maven >>>> 3 as their base requirements. >>>> >>>> What do people think is the right approach in terms of what stays on >>>> trunk and what goes on a branch, and whether to do anything >>>> distinctive to the version numbers? >>>> >>> >>> Finally, someone's stepping up for such a good change. Though, I think >>> some important stuff needs to be considered first: >>> >>> 1. Announce 2.x EOL and give people at least 3 months to switch. >> >> >> >> Already done and site updated > > > Just had a hard time to find this information on the (front) page. > I think a mere: 2014-02-18 End of Life EoL notes, announce is not enough. I > would have expected something like this on the front page: > > Looking for Maven 2? > // Either some text > // or the link to the EoL announcement. > > >>> 2. If you align plugins with a 3.0 baseline, I would bump at least a >>> minor >>> version, maybe even a major one. >> >> >> >> I think bumping a major version would be fair and proper... But we don't >> have a formal policy yet, and a minor version bump might be valid too. > > > Beside the general draft [1] we do already have two good policies. Even one > at Apache APR [2], and semver.org. > > Micahel > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy > [2] https://apr.apache.org/versioning.html#strategy > > > > --------------------------------------------------------------------- > 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
