First, thanks Stephen (and others) for working on this. I think it's very important that we use version numbers consistently and also communicate what they mean to our users. We should also be very clear with what to expect.
I agree with Dennis and Brett here, I think we could simplify by just stating what we "promise" to do. Not what could possibly happen. This will set up the right expectations for the users. Wrt to the 18 months for security maintenance lines for core, I think that could be to start out with. If we see that it's too short of a windows we could extend it. Either as just a one time thing or extend the general policy. For plugins (including the parent pom) and components/wagon, I think we should go with just one line. We should set the right expectations and not promise too much. And yes, let's bring out the JDK requirement policy to a separate document. It's a separate topic I think. /Anders On Mon, Feb 24, 2014 at 12:07 AM, Brett Porter <br...@apache.org> wrote: > On 24 Feb 2014, at 2:48 am, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > I guess we need to clear up what I mean by a maintenance line... > > > > We *can/may* cut releases on maintenance / security line... Does not mean > > we *will* more that for non-security/maintenance lines there is ZERO > > possibility of us cutting a release... > > As another data point, my reaction was the same as as Dennis' on first > reading. I think the doc could be simplified - perhaps it is more helpful > to describe what will be done, not what can/may be done, but then have > avenues to add those when possible. Say, start with the last stable release > as a the maintenance/security line, but add others where there are willing > volunteers to continue maintaining it. IIUC, if a security issue came in > the next few weeks, it'd probably be fixed in 3.2.x and 3.0.x (not > upgrading due to some plugin incompatibilities), but not 3.1.x (expected to > be a smooth upgrade to 3.2.x). Is that what would realistically happen? > > On the components/plugins/wagon side, I don't think there's much need for > older lines, since there are unlikely to be downstream users that can't > upgrade to the latest. The only exception I could think of historically was > when Site was maintained for Maven 2. > > - Brett > > -- > Brett Porter @brettporter > http://brettporter.wordpress.com/ > http://au.linkedin.com/in/brettporter > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
