You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2014/02/21 16:10:50 UTC
[DISCUSS] Adopt a version policy and a support policy to go with it.
For discussion... and tearing into... and Chris shouting out that IBM
supports Java 6 for yonks...
https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
I think we need a version policy and the best way to get one is to put a
draft together and let people edit it to something that we all can be happy
with.
Constructive feedback welcome... in fact committers editing the doc is
encouraged...
Please leave the DRAFT heading at the top.
If a consensus emerges we will have a vote and put the resulting policy on
the project site as opposed to a draft document on the wiki.
-Stephen
Re: [DISCUSS] Adopt a version policy and a support policy to go with it.
Posted by Baptiste Mathus <bm...@batmat.net>.
Le 21 févr. 2014 16:39, "Igor Fedorenko" <ig...@ifedorenko.com> a écrit :
>
> I think this is reasonable.
>
> One observation. Maven does not have an API, plugins and projects can
> access pretty much anything from the core. Add to this three distinct
> user communities -- (end) users, plugin developers and embedders -- and
> I think pretty much any change will break somebody. This means that
> INCREMENTAL version component will be more or less reserved for release
> respins and many dependency changes will require MAJOR bump. Not saying
> there is anything wrong with this, just something we'll need to educated
> our users about.
Not sure it's really that feasible for maven core, but wouldn't be at least
a part of the solution to clarify what's considered internal and what's
considered API/SPI? Maybe renaming or moving some packages to ones
containing 'internal' or things like that?
At least
>
> --
> Regards,
> Igor
>
>
>
>
> On 2/21/2014, 10:10, Stephen Connolly wrote:
>>
>> For discussion... and tearing into... and Chris shouting out that IBM
>> supports Java 6 for yonks...
>>
>> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>>
>> I think we need a version policy and the best way to get one is to put a
>> draft together and let people edit it to something that we all can be
happy
>> with.
>>
>> Constructive feedback welcome... in fact committers editing the doc is
>> encouraged...
>>
>> Please leave the DRAFT heading at the top.
>>
>> If a consensus emerges we will have a vote and put the resulting policy
on
>> the project site as opposed to a draft document on the wiki.
>>
>> -Stephen
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: [DISCUSS] Adopt a version policy and a support policy to go with
it.
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I think this is reasonable.
One observation. Maven does not have an API, plugins and projects can
access pretty much anything from the core. Add to this three distinct
user communities -- (end) users, plugin developers and embedders -- and
I think pretty much any change will break somebody. This means that
INCREMENTAL version component will be more or less reserved for release
respins and many dependency changes will require MAJOR bump. Not saying
there is anything wrong with this, just something we'll need to educated
our users about.
--
Regards,
Igor
On 2/21/2014, 10:10, Stephen Connolly wrote:
> For discussion... and tearing into... and Chris shouting out that IBM
> supports Java 6 for yonks...
>
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>
> I think we need a version policy and the best way to get one is to put a
> draft together and let people edit it to something that we all can be happy
> with.
>
> Constructive feedback welcome... in fact committers editing the doc is
> encouraged...
>
> Please leave the DRAFT heading at the top.
>
> If a consensus emerges we will have a vote and put the resulting policy on
> the project site as opposed to a draft document on the wiki.
>
> -Stephen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Adopt a version policy and a support policy to go with it.
Posted by Anders Hammar <an...@hammar.net>.
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.connolly@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Adopt a version policy and a support policy to go with it.
Posted by Brett Porter <br...@apache.org>.
On 24 Feb 2014, at 2:48 am, Stephen Connolly <st...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Adopt a version policy and a support policy to go with it.
Posted by Stephen Connolly <st...@gmail.com>.
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...
On Sunday, 23 February 2014, Dennis Lundberg <de...@apache.org> wrote:
> I think the parts about which JRE to depend upon deserves its own
> document, because it is something that affects our users much more
> that which version numbers we use. The same goes for which version of
> Maven Core a plugin/component can require. That being said, your
> proposal is a great starting point for discussions about version
> numbering.
>
> Maven Core
>
> Looking at our history for core, the 18 month rules in there are a bit
> hard I think. That would mean that 3.0.x would be EOL now. Having a
> fixed time is good, I just think that it needs to be longer. But that
> also depends on our cadence of minor releases going forward.
>
> Maven Plugins
>
> The current proposal is a huge step from what we currently do, in
> terms of version lines. I can't recall a single maintenance line or
> security line from memory. The only maintenance line that I know of
> has been for the Site Plugin, where we kept one the the previous MAJOR
> version, i.e. 2.x.
>
> Provided we do not change Maven version or Java version I think that
> we can live with just a development line. Should any security
> vulnerabilities be found, we can just fix it in trunk and release a
> patch version. Or if to much has happened on trunk, create branch from
> the previous MAJOR.MINOR and do a patch release from it.
>
> Maven Shared Components
> As for plugins the proposal is a big step from what we do today. Do we
> have the time and man hours to maintain for example four versions of
> wagon?
>
>
> On Fri, Feb 21, 2014 at 4:10 PM, Stephen Connolly
> <stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> > For discussion... and tearing into... and Chris shouting out that IBM
> > supports Java 6 for yonks...
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> >
> > I think we need a version policy and the best way to get one is to put a
> > draft together and let people edit it to something that we all can be
> happy
> > with.
> >
> > Constructive feedback welcome... in fact committers editing the doc is
> > encouraged...
> >
> > Please leave the DRAFT heading at the top.
> >
> > If a consensus emerges we will have a vote and put the resulting policy
> on
> > the project site as opposed to a draft document on the wiki.
> >
> > -Stephen
>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
--
Sent from my phone
Re: [DISCUSS] Adopt a version policy and a support policy to go with it.
Posted by Dennis Lundberg <de...@apache.org>.
I think the parts about which JRE to depend upon deserves its own
document, because it is something that affects our users much more
that which version numbers we use. The same goes for which version of
Maven Core a plugin/component can require. That being said, your
proposal is a great starting point for discussions about version
numbering.
Maven Core
Looking at our history for core, the 18 month rules in there are a bit
hard I think. That would mean that 3.0.x would be EOL now. Having a
fixed time is good, I just think that it needs to be longer. But that
also depends on our cadence of minor releases going forward.
Maven Plugins
The current proposal is a huge step from what we currently do, in
terms of version lines. I can't recall a single maintenance line or
security line from memory. The only maintenance line that I know of
has been for the Site Plugin, where we kept one the the previous MAJOR
version, i.e. 2.x.
Provided we do not change Maven version or Java version I think that
we can live with just a development line. Should any security
vulnerabilities be found, we can just fix it in trunk and release a
patch version. Or if to much has happened on trunk, create branch from
the previous MAJOR.MINOR and do a patch release from it.
Maven Shared Components
As for plugins the proposal is a big step from what we do today. Do we
have the time and man hours to maintain for example four versions of
wagon?
On Fri, Feb 21, 2014 at 4:10 PM, Stephen Connolly
<st...@gmail.com> wrote:
> For discussion... and tearing into... and Chris shouting out that IBM
> supports Java 6 for yonks...
>
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>
> I think we need a version policy and the best way to get one is to put a
> draft together and let people edit it to something that we all can be happy
> with.
>
> Constructive feedback welcome... in fact committers editing the doc is
> encouraged...
>
> Please leave the DRAFT heading at the top.
>
> If a consensus emerges we will have a vote and put the resulting policy on
> the project site as opposed to a draft document on the wiki.
>
> -Stephen
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org