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/19 10:22:12 UTC

What is in a version? (was Towards faster releases)

I think we have a bit of a disagreement about what changes should be going
into different version numbers.

To my mind, we should be using the convention that most people expect, i.e.
semver[1]-ish. I am not saying that we need to be super-strict in following
the exact semver specification, but I do think that we should be following
the semver spirit:

Given a version number MAJOR.MINOR.PATCH, increment the:
> MAJOR version when you make incompatible API changes,
> MINOR version when you add functionality in a backwards-compatible manner,
> and
> PATCH version when you make backwards-compatible bug fixes.


So with the above principle, the only changes that should be going into the
3.2.x line should be backwards compatible bug fixes.

Adding functionality should be going towards 3.3.x

And the modelVersion 5.0.0 stuff should be going towards 4.0.x

If I look at the issue tracker for 3.2.2:
http://jira.codehaus.org/issues/?jql=fixVersion%20%3D%20%223.2.2%22%20AND%20project%20%3D%20MNG

I currently see 9 issues:

Improvements: MNG-5589, MNG-5587, MNG-5577, MNG-4715, MNG-1958
Bug fixes: MNG-5552, MNG-5475, MNG-5219, MNG-3559

If we accept the principle that only bug fixes should be going into
patch/incremental releases then those 5 improvements are out of scope for
3.2.x

If we dig a bit further:

* MNG-5552's fix involves extending the API, so that would be 3.3.x
* MNG-5474 may introduce regressions if there is anyone depending on the
current behaviour, so that could be seen as 3.3.x

So my aim of faster releases becomes as soon as we get a fix for either
MNG-5219 or MNG-3559 committed on the 3.2.x release line... then we should
consider cutting a release of that line.

That is the context in which I am suggesting that we could move to faster
releases...

Now there is a big *if* that I ack was my implicit unstated understanding
when I started the "Towards faster releases" thread... namely that:

    A Patch/Incremental version is backwards compatible bug fixes only. No
additional functionality. Additional functionality goes in a new minor
version.

I think the resistance to my suggestion from Jason is either from a
different world view on what should go into a patch/incremental version...
or perhaps just forgetting that the scope of patch/incremental versions is
what I suggest it is.

So my question to the Maven developers is this:

What types of things should be eligible for a patch/incremental release of
Maven?

Is it "backwards-compatible bug fixes" only?

Is it "backwards-compatible bug fixes and api improvements"?

Is it "any bug fix and backwards-compatible api improvements"?

Is it something else?

Keep in mind that users out there could well be expecting something
semver-ish... as that is a meme that seems to me to be catching on...

FYI: If the consensus view is different from `"backwards-compatible bug
fixes" only` then there is no point in pursuing my plan of weekly checks
for a new patch release and cutting such a release if it is releasable, and
I will drop them (we can keep the tooling I have put in place as it will
help improve our quality... and I intend improving that tooling anyway).
But if the consensus is that patch/incremental versions should be
`"backwards-compatible bug fixes" only` then I see no good reason why we
should hold onto those fixes any longer than a week after they have been
committed. New features can go straight into the 3.3.x branch and I (and
others) can cherry pick the fixes from the 3.3.x branch back to 3.2.x and
cut those releases when they are ready. (Which was what I thought my
proposal was... but re-reading I ack that it was not as obvious to the
reader as it was to the writer ;-) )

-Stephen

  [1]: http://semver.org/

Re: What is in a version? (was Towards faster releases)

Posted by Stephen Connolly <st...@gmail.com>.
On 20 February 2014 21:30, Dennis Lundberg <de...@gmail.com> wrote:

> I am in favor of using a stricter-than-today SEMVER-ish approach to
> our releases, not just in core but in all our releases.
>
> To me it's really easy. Just check the issue types in JIRA and let
> that decide which version number will come next. If there are only
> bugs fixed then it's a patch-release, if there are improvements and
> backwards-compatible new features then it's a minor release.
>

Yep... does mean that we need to scrub the issues to ensure that issue
types are correct... but we need to scrub the issues anyway


>
> That being said it will still take some planning to get suitable
> chunks of work into each release.
>
> There's also the dilemma of how many minor versions we should
> maintain, by back-porting and applying patches to them.
>

I think we can legitimately apply a different policy for core versus
plugins.

For plugins the policy I would suggest is:

* Maintain the latest minor release only (no backporting bug fixes to
previous minor release)

* Security fixes to previous minor release.

* This means that we only support fixing issues one and one back for
plugins, so plugins in effect are EOL once there have been two new minor
releases of that plugin

For core the policy I would suggest is:

* Maintain the latest minor release

* Maintain the previous minor release (backport bug fixes from latest minor
release)

* Security fixes for all previous minor releases released within the last
12 months

* End of life releases older than 12 months. (because if we are not even
providing security releases then it is by definition EOL)

If we want to go to 24 months for security fixes that's fine by me... we
should pick some time period and stick to it.

-Stephen


> On Wed, Feb 19, 2014 at 10:22 AM, Stephen Connolly
> <st...@gmail.com> wrote:
> > I think we have a bit of a disagreement about what changes should be
> going
> > into different version numbers.
> >
> > To my mind, we should be using the convention that most people expect,
> i.e.
> > semver[1]-ish. I am not saying that we need to be super-strict in
> following
> > the exact semver specification, but I do think that we should be
> following
> > the semver spirit:
> >
> > Given a version number MAJOR.MINOR.PATCH, increment the:
> >> MAJOR version when you make incompatible API changes,
> >> MINOR version when you add functionality in a backwards-compatible
> manner,
> >> and
> >> PATCH version when you make backwards-compatible bug fixes.
> >
> >
> > So with the above principle, the only changes that should be going into
> the
> > 3.2.x line should be backwards compatible bug fixes.
> >
> > Adding functionality should be going towards 3.3.x
> >
> > And the modelVersion 5.0.0 stuff should be going towards 4.0.x
> >
> > If I look at the issue tracker for 3.2.2:
> >
> http://jira.codehaus.org/issues/?jql=fixVersion%20%3D%20%223.2.2%22%20AND%20project%20%3D%20MNG
> >
> > I currently see 9 issues:
> >
> > Improvements: MNG-5589, MNG-5587, MNG-5577, MNG-4715, MNG-1958
> > Bug fixes: MNG-5552, MNG-5475, MNG-5219, MNG-3559
> >
> > If we accept the principle that only bug fixes should be going into
> > patch/incremental releases then those 5 improvements are out of scope for
> > 3.2.x
> >
> > If we dig a bit further:
> >
> > * MNG-5552's fix involves extending the API, so that would be 3.3.x
> > * MNG-5474 may introduce regressions if there is anyone depending on the
> > current behaviour, so that could be seen as 3.3.x
> >
> > So my aim of faster releases becomes as soon as we get a fix for either
> > MNG-5219 or MNG-3559 committed on the 3.2.x release line... then we
> should
> > consider cutting a release of that line.
> >
> > That is the context in which I am suggesting that we could move to faster
> > releases...
> >
> > Now there is a big *if* that I ack was my implicit unstated understanding
> > when I started the "Towards faster releases" thread... namely that:
> >
> >     A Patch/Incremental version is backwards compatible bug fixes only.
> No
> > additional functionality. Additional functionality goes in a new minor
> > version.
> >
> > I think the resistance to my suggestion from Jason is either from a
> > different world view on what should go into a patch/incremental
> version...
> > or perhaps just forgetting that the scope of patch/incremental versions
> is
> > what I suggest it is.
> >
> > So my question to the Maven developers is this:
> >
> > What types of things should be eligible for a patch/incremental release
> of
> > Maven?
> >
> > Is it "backwards-compatible bug fixes" only?
> >
> > Is it "backwards-compatible bug fixes and api improvements"?
> >
> > Is it "any bug fix and backwards-compatible api improvements"?
> >
> > Is it something else?
> >
> > Keep in mind that users out there could well be expecting something
> > semver-ish... as that is a meme that seems to me to be catching on...
> >
> > FYI: If the consensus view is different from `"backwards-compatible bug
> > fixes" only` then there is no point in pursuing my plan of weekly checks
> > for a new patch release and cutting such a release if it is releasable,
> and
> > I will drop them (we can keep the tooling I have put in place as it will
> > help improve our quality... and I intend improving that tooling anyway).
> > But if the consensus is that patch/incremental versions should be
> > `"backwards-compatible bug fixes" only` then I see no good reason why we
> > should hold onto those fixes any longer than a week after they have been
> > committed. New features can go straight into the 3.3.x branch and I (and
> > others) can cherry pick the fixes from the 3.3.x branch back to 3.2.x and
> > cut those releases when they are ready. (Which was what I thought my
> > proposal was... but re-reading I ack that it was not as obvious to the
> > reader as it was to the writer ;-) )
> >
> > -Stephen
> >
> >   [1]: http://semver.org/
>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: What is in a version? (was Towards faster releases)

Posted by Dennis Lundberg <de...@gmail.com>.
I am in favor of using a stricter-than-today SEMVER-ish approach to
our releases, not just in core but in all our releases.

To me it's really easy. Just check the issue types in JIRA and let
that decide which version number will come next. If there are only
bugs fixed then it's a patch-release, if there are improvements and
backwards-compatible new features then it's a minor release.

That being said it will still take some planning to get suitable
chunks of work into each release.

There's also the dilemma of how many minor versions we should
maintain, by back-porting and applying patches to them.

On Wed, Feb 19, 2014 at 10:22 AM, Stephen Connolly
<st...@gmail.com> wrote:
> I think we have a bit of a disagreement about what changes should be going
> into different version numbers.
>
> To my mind, we should be using the convention that most people expect, i.e.
> semver[1]-ish. I am not saying that we need to be super-strict in following
> the exact semver specification, but I do think that we should be following
> the semver spirit:
>
> Given a version number MAJOR.MINOR.PATCH, increment the:
>> MAJOR version when you make incompatible API changes,
>> MINOR version when you add functionality in a backwards-compatible manner,
>> and
>> PATCH version when you make backwards-compatible bug fixes.
>
>
> So with the above principle, the only changes that should be going into the
> 3.2.x line should be backwards compatible bug fixes.
>
> Adding functionality should be going towards 3.3.x
>
> And the modelVersion 5.0.0 stuff should be going towards 4.0.x
>
> If I look at the issue tracker for 3.2.2:
> http://jira.codehaus.org/issues/?jql=fixVersion%20%3D%20%223.2.2%22%20AND%20project%20%3D%20MNG
>
> I currently see 9 issues:
>
> Improvements: MNG-5589, MNG-5587, MNG-5577, MNG-4715, MNG-1958
> Bug fixes: MNG-5552, MNG-5475, MNG-5219, MNG-3559
>
> If we accept the principle that only bug fixes should be going into
> patch/incremental releases then those 5 improvements are out of scope for
> 3.2.x
>
> If we dig a bit further:
>
> * MNG-5552's fix involves extending the API, so that would be 3.3.x
> * MNG-5474 may introduce regressions if there is anyone depending on the
> current behaviour, so that could be seen as 3.3.x
>
> So my aim of faster releases becomes as soon as we get a fix for either
> MNG-5219 or MNG-3559 committed on the 3.2.x release line... then we should
> consider cutting a release of that line.
>
> That is the context in which I am suggesting that we could move to faster
> releases...
>
> Now there is a big *if* that I ack was my implicit unstated understanding
> when I started the "Towards faster releases" thread... namely that:
>
>     A Patch/Incremental version is backwards compatible bug fixes only. No
> additional functionality. Additional functionality goes in a new minor
> version.
>
> I think the resistance to my suggestion from Jason is either from a
> different world view on what should go into a patch/incremental version...
> or perhaps just forgetting that the scope of patch/incremental versions is
> what I suggest it is.
>
> So my question to the Maven developers is this:
>
> What types of things should be eligible for a patch/incremental release of
> Maven?
>
> Is it "backwards-compatible bug fixes" only?
>
> Is it "backwards-compatible bug fixes and api improvements"?
>
> Is it "any bug fix and backwards-compatible api improvements"?
>
> Is it something else?
>
> Keep in mind that users out there could well be expecting something
> semver-ish... as that is a meme that seems to me to be catching on...
>
> FYI: If the consensus view is different from `"backwards-compatible bug
> fixes" only` then there is no point in pursuing my plan of weekly checks
> for a new patch release and cutting such a release if it is releasable, and
> I will drop them (we can keep the tooling I have put in place as it will
> help improve our quality... and I intend improving that tooling anyway).
> But if the consensus is that patch/incremental versions should be
> `"backwards-compatible bug fixes" only` then I see no good reason why we
> should hold onto those fixes any longer than a week after they have been
> committed. New features can go straight into the 3.3.x branch and I (and
> others) can cherry pick the fixes from the 3.3.x branch back to 3.2.x and
> cut those releases when they are ready. (Which was what I thought my
> proposal was... but re-reading I ack that it was not as obvious to the
> reader as it was to the writer ;-) )
>
> -Stephen
>
>   [1]: http://semver.org/



-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: What is in a version? (was Towards faster releases)

Posted by Jason van Zyl <ja...@takari.io>.
So we have nightlies/weeklies and post to the dev list, that's fine.

On Feb 19, 2014, at 12:27 PM, Benson Margulies <bi...@gmail.com> wrote:

> I need to remind people about the Apache rules here. Yes you can have
> weekly builds. No you can't 'advertise them' in any way that is likely
> to attract the attention of mere users as opposed to people engaged in
> the development community. Please don't shoot me, I'm just the
> messenger here.
> 
> On Wed, Feb 19, 2014 at 11:25 AM, Jason van Zyl <ja...@takari.io> wrote:
>> Agreed, if they small enhancements then I don't really want to release 4 things issues in a patch release and then another 5. Generally I'm fine with small enhancements, or small fixes going into patch releases, along with anything marked @provisional as I'd rather have the experimental code in a release then rotting in a branch.
>> 
>> That said I'm not averse to calling the next release 3.3.0. A 3.2.2 isn't strictly semver and I certainly would like to have this for 4.0.0 but right now I don't have a strong opinion. If we want to decide to use semver (which we never have) and want to try now that's fine. We need to get there at some point.
>> 
>> But I'm still off the mind the best approach is what Igor outlined. No official weekly releases, we just make the infrastructure work to publish weekly integration builds and let people consume them as required, and any changes in those get rolled up into official release schedule.
>> 
>> On Feb 19, 2014, at 6:36 AM, Paul Benedict <pb...@apache.org> wrote:
>> 
>>> I don't see any necessity to restrict patch releases to patches only -- as
>>> long as any new functionality is a tiny enhancement and doesn't make
>>> incompatibilities. Save medium/major structural changes for a new minor
>>> version.
>>> 
>>> 
>>> On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies <bi...@gmail.com>wrote:
>>> 
>>>> A bit of a recap:
>>>> 
>>>> Let's say that our goal as a group was to be very responsive to user's
>>>> bug reports.
>>>> 
>>>> So, we'd want to make fixes and releases, 'promptly', for some
>>>> definition of prompt.
>>>> 
>>>> But no one will install those releases if they are not confident that
>>>> they are, in fact, not going to have unexpected consequences.
>>>> 
>>>> From a black-box standpoint, this can only be achieved with really
>>>> strong integration tests.
>>>> 
>>>> From a white-box standpoint, it seems to me that the Maven core has a
>>>> tendency towards complex interactions in which a fix to problem (a)
>>>> can have unexpected consequence (b).
>>>> 
>>>> So, either way, Jason's views about testing seem spot-on. This leaves
>>>> a question: should we be trying, still, to follow up a 3.2.0 with a
>>>> pure bugfix 3.2.1, and holding off on structural repairs or new
>>>> features until 3.3? One view is that we should try to get some of the
>>>> tests improved and some of the structural repairs done before we make
>>>> any attempt at semver/responsive releases. The other view is that
>>>> should try to deliver on semver as best we can.
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Cheers,
>>> Paul
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>> 
>> First, the taking in of scattered particulars under one Idea,
>> so that everyone understands what is being talked about ... Second,
>> the separation of the Idea into parts, by dividing it at the joints,
>> as nature directs, not breaking any limb in half as a bad carver might.
>> 
>>  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

Re: What is in a version? (was Towards faster releases)

Posted by Benson Margulies <bi...@gmail.com>.
I need to remind people about the Apache rules here. Yes you can have
weekly builds. No you can't 'advertise them' in any way that is likely
to attract the attention of mere users as opposed to people engaged in
the development community. Please don't shoot me, I'm just the
messenger here.

On Wed, Feb 19, 2014 at 11:25 AM, Jason van Zyl <ja...@takari.io> wrote:
> Agreed, if they small enhancements then I don't really want to release 4 things issues in a patch release and then another 5. Generally I'm fine with small enhancements, or small fixes going into patch releases, along with anything marked @provisional as I'd rather have the experimental code in a release then rotting in a branch.
>
> That said I'm not averse to calling the next release 3.3.0. A 3.2.2 isn't strictly semver and I certainly would like to have this for 4.0.0 but right now I don't have a strong opinion. If we want to decide to use semver (which we never have) and want to try now that's fine. We need to get there at some point.
>
> But I'm still off the mind the best approach is what Igor outlined. No official weekly releases, we just make the infrastructure work to publish weekly integration builds and let people consume them as required, and any changes in those get rolled up into official release schedule.
>
> On Feb 19, 2014, at 6:36 AM, Paul Benedict <pb...@apache.org> wrote:
>
>> I don't see any necessity to restrict patch releases to patches only -- as
>> long as any new functionality is a tiny enhancement and doesn't make
>> incompatibilities. Save medium/major structural changes for a new minor
>> version.
>>
>>
>> On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies <bi...@gmail.com>wrote:
>>
>>> A bit of a recap:
>>>
>>> Let's say that our goal as a group was to be very responsive to user's
>>> bug reports.
>>>
>>> So, we'd want to make fixes and releases, 'promptly', for some
>>> definition of prompt.
>>>
>>> But no one will install those releases if they are not confident that
>>> they are, in fact, not going to have unexpected consequences.
>>>
>>> From a black-box standpoint, this can only be achieved with really
>>> strong integration tests.
>>>
>>> From a white-box standpoint, it seems to me that the Maven core has a
>>> tendency towards complex interactions in which a fix to problem (a)
>>> can have unexpected consequence (b).
>>>
>>> So, either way, Jason's views about testing seem spot-on. This leaves
>>> a question: should we be trying, still, to follow up a 3.2.0 with a
>>> pure bugfix 3.2.1, and holding off on structural repairs or new
>>> features until 3.3? One view is that we should try to get some of the
>>> tests improved and some of the structural repairs done before we make
>>> any attempt at semver/responsive releases. The other view is that
>>> should try to deliver on semver as best we can.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Paul
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
>   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: What is in a version? (was Towards faster releases)

Posted by Jason van Zyl <ja...@takari.io>.
Agreed, if they small enhancements then I don't really want to release 4 things issues in a patch release and then another 5. Generally I'm fine with small enhancements, or small fixes going into patch releases, along with anything marked @provisional as I'd rather have the experimental code in a release then rotting in a branch.

That said I'm not averse to calling the next release 3.3.0. A 3.2.2 isn't strictly semver and I certainly would like to have this for 4.0.0 but right now I don't have a strong opinion. If we want to decide to use semver (which we never have) and want to try now that's fine. We need to get there at some point.

But I'm still off the mind the best approach is what Igor outlined. No official weekly releases, we just make the infrastructure work to publish weekly integration builds and let people consume them as required, and any changes in those get rolled up into official release schedule.

On Feb 19, 2014, at 6:36 AM, Paul Benedict <pb...@apache.org> wrote:

> I don't see any necessity to restrict patch releases to patches only -- as
> long as any new functionality is a tiny enhancement and doesn't make
> incompatibilities. Save medium/major structural changes for a new minor
> version.
> 
> 
> On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies <bi...@gmail.com>wrote:
> 
>> A bit of a recap:
>> 
>> Let's say that our goal as a group was to be very responsive to user's
>> bug reports.
>> 
>> So, we'd want to make fixes and releases, 'promptly', for some
>> definition of prompt.
>> 
>> But no one will install those releases if they are not confident that
>> they are, in fact, not going to have unexpected consequences.
>> 
>> From a black-box standpoint, this can only be achieved with really
>> strong integration tests.
>> 
>> From a white-box standpoint, it seems to me that the Maven core has a
>> tendency towards complex interactions in which a fix to problem (a)
>> can have unexpected consequence (b).
>> 
>> So, either way, Jason's views about testing seem spot-on. This leaves
>> a question: should we be trying, still, to follow up a 3.2.0 with a
>> pure bugfix 3.2.1, and holding off on structural repairs or new
>> features until 3.3? One view is that we should try to get some of the
>> tests improved and some of the structural repairs done before we make
>> any attempt at semver/responsive releases. The other view is that
>> should try to deliver on semver as best we can.
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
> 
> 
> -- 
> Cheers,
> Paul

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

Re: What is in a version? (was Towards faster releases)

Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,

If you include new functionality this means that according to semver you increase the second digit, which means conservative users will do this upgrade step not so easy anymore  (and therefore miss all future fixes).

I would rather include enhancements anyway but divert from strict semver: The most visible change would be that the minimum prerequisites for a plugin needs to observe the last digit (like it is today). So the meanings of the digits are more risk than compatibility oriented.

Applying stricter semver would require to not ship enhancements until a new functional release is cut (and then deciding if older functional releases still get bugfixes or not).

Bernd

BTW: I think this is totally Independent of the topic if running Integration builds with automatic promotions.

> Am 19.02.2014 um 15:36 schrieb Paul Benedict <pb...@apache.org>:
> 
> I don't see any necessity to restrict patch releases to patches only -- as
> long as any new functionality is a tiny enhancement and doesn't make
> incompatibilities. Save medium/major structural changes for a new minor
> version.
> 
> 
> On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies <bi...@gmail.com>wrote:
> 
>> A bit of a recap:
>> 
>> Let's say that our goal as a group was to be very responsive to user's
>> bug reports.
>> 
>> So, we'd want to make fixes and releases, 'promptly', for some
>> definition of prompt.
>> 
>> But no one will install those releases if they are not confident that
>> they are, in fact, not going to have unexpected consequences.
>> 
>> From a black-box standpoint, this can only be achieved with really
>> strong integration tests.
>> 
>> From a white-box standpoint, it seems to me that the Maven core has a
>> tendency towards complex interactions in which a fix to problem (a)
>> can have unexpected consequence (b).
>> 
>> So, either way, Jason's views about testing seem spot-on. This leaves
>> a question: should we be trying, still, to follow up a 3.2.0 with a
>> pure bugfix 3.2.1, and holding off on structural repairs or new
>> features until 3.3? One view is that we should try to get some of the
>> tests improved and some of the structural repairs done before we make
>> any attempt at semver/responsive releases. The other view is that
>> should try to deliver on semver as best we can.
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> -- 
> Cheers,
> Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: What is in a version? (was Towards faster releases)

Posted by Paul Benedict <pb...@apache.org>.
I don't see any necessity to restrict patch releases to patches only -- as
long as any new functionality is a tiny enhancement and doesn't make
incompatibilities. Save medium/major structural changes for a new minor
version.


On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies <bi...@gmail.com>wrote:

> A bit of a recap:
>
> Let's say that our goal as a group was to be very responsive to user's
> bug reports.
>
> So, we'd want to make fixes and releases, 'promptly', for some
> definition of prompt.
>
> But no one will install those releases if they are not confident that
> they are, in fact, not going to have unexpected consequences.
>
> From a black-box standpoint, this can only be achieved with really
> strong integration tests.
>
> From a white-box standpoint, it seems to me that the Maven core has a
> tendency towards complex interactions in which a fix to problem (a)
> can have unexpected consequence (b).
>
> So, either way, Jason's views about testing seem spot-on. This leaves
> a question: should we be trying, still, to follow up a 3.2.0 with a
> pure bugfix 3.2.1, and holding off on structural repairs or new
> features until 3.3? One view is that we should try to get some of the
> tests improved and some of the structural repairs done before we make
> any attempt at semver/responsive releases. The other view is that
> should try to deliver on semver as best we can.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Cheers,
Paul

Re: What is in a version? (was Towards faster releases)

Posted by Benson Margulies <bi...@gmail.com>.
A bit of a recap:

Let's say that our goal as a group was to be very responsive to user's
bug reports.

So, we'd want to make fixes and releases, 'promptly', for some
definition of prompt.

But no one will install those releases if they are not confident that
they are, in fact, not going to have unexpected consequences.

>From a black-box standpoint, this can only be achieved with really
strong integration tests.

>From a white-box standpoint, it seems to me that the Maven core has a
tendency towards complex interactions in which a fix to problem (a)
can have unexpected consequence (b).

So, either way, Jason's views about testing seem spot-on. This leaves
a question: should we be trying, still, to follow up a 3.2.0 with a
pure bugfix 3.2.1, and holding off on structural repairs or new
features until 3.3? One view is that we should try to get some of the
tests improved and some of the structural repairs done before we make
any attempt at semver/responsive releases. The other view is that
should try to deliver on semver as best we can.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: What is in a version? (was Towards faster releases)

Posted by Baptiste Mathus <ml...@batmat.net>.
+1.  Totally for a (nonstrict) semver Maven.


Copied from the other thread for reference:

I think you'd have a lot more confidence in moving up to a newer maven.
>
> Enterprises will move to versions that they perceive as low risk. A true
> maintenance mode with a regular predictable release cadence where critical
> issues can get fixed fast will give them low risk.
>

+1.
Btw, I think this is where Jason's opinion could be converging. One of the
main given reasons for not delivering more versions is that slow-moving
enterprises wouldn't pick them anyway, so it'd be just wasted time.
BUT, if it became well-known that Maven respects some form of semver, then
those companies might certainly upgrade from 3.3.7 to 3.3.10 more
confidently (and more often).

I can't see a lot of reasons why that would/couldn't work.


2014-02-19 10:38 GMT+01:00 Anders Hammar <an...@hammar.net>:

> Thanks for bringing this up, Stephen!
>
> My +1 goes to "backwards-compatible bug fixes (only)" in a bugfix/patch
> release.
> If we could decide (whatever we decide) what changes goes into what sort of
> release, I think that would help the community a lot. I personally think
> that re-using somehting like semver would be very good and in the spirit of
> Maven's theme of best-practices. However, I fully appreciate that opinions
> on "best-practice" in this case could be different than mine.
>
> I also fully agree with Jason on how things work with larger companies,
> where upgrading something like Maven is a big process. So if we have bugfix
> releases where we carefully introduce on fixed for known bugs, I think this
> would be very good and simplify that process.
>
> Also, out of a PR perspective, I think that increasing the minor version
> when we add new functionality (doesn't have to be from a user perspective
> but could be technical) is good. It shows that Maven is moving forward.
>
> /Anders
>
>
> On Wed, Feb 19, 2014 at 10:22 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > I think we have a bit of a disagreement about what changes should be
> going
> > into different version numbers.
> >
> > To my mind, we should be using the convention that most people expect,
> i.e.
> > semver[1]-ish. I am not saying that we need to be super-strict in
> following
> > the exact semver specification, but I do think that we should be
> following
> > the semver spirit:
> >
> > Given a version number MAJOR.MINOR.PATCH, increment the:
> > > MAJOR version when you make incompatible API changes,
> > > MINOR version when you add functionality in a backwards-compatible
> > manner,
> > > and
> > > PATCH version when you make backwards-compatible bug fixes.
> >
> >
> > So with the above principle, the only changes that should be going into
> the
> > 3.2.x line should be backwards compatible bug fixes.
> >
> > Adding functionality should be going towards 3.3.x
> >
> > And the modelVersion 5.0.0 stuff should be going towards 4.0.x
> >
> > If I look at the issue tracker for 3.2.2:
> >
> >
> http://jira.codehaus.org/issues/?jql=fixVersion%20%3D%20%223.2.2%22%20AND%20project%20%3D%20MNG
> >
> > I currently see 9 issues:
> >
> > Improvements: MNG-5589, MNG-5587, MNG-5577, MNG-4715, MNG-1958
> > Bug fixes: MNG-5552, MNG-5475, MNG-5219, MNG-3559
> >
> > If we accept the principle that only bug fixes should be going into
> > patch/incremental releases then those 5 improvements are out of scope for
> > 3.2.x
> >
> > If we dig a bit further:
> >
> > * MNG-5552's fix involves extending the API, so that would be 3.3.x
> > * MNG-5474 may introduce regressions if there is anyone depending on the
> > current behaviour, so that could be seen as 3.3.x
> >
> > So my aim of faster releases becomes as soon as we get a fix for either
> > MNG-5219 or MNG-3559 committed on the 3.2.x release line... then we
> should
> > consider cutting a release of that line.
> >
> > That is the context in which I am suggesting that we could move to faster
> > releases...
> >
> > Now there is a big *if* that I ack was my implicit unstated understanding
> > when I started the "Towards faster releases" thread... namely that:
> >
> >     A Patch/Incremental version is backwards compatible bug fixes only.
> No
> > additional functionality. Additional functionality goes in a new minor
> > version.
> >
> > I think the resistance to my suggestion from Jason is either from a
> > different world view on what should go into a patch/incremental
> version...
> > or perhaps just forgetting that the scope of patch/incremental versions
> is
> > what I suggest it is.
> >
> > So my question to the Maven developers is this:
> >
> > What types of things should be eligible for a patch/incremental release
> of
> > Maven?
> >
> > Is it "backwards-compatible bug fixes" only?
> >
> > Is it "backwards-compatible bug fixes and api improvements"?
> >
> > Is it "any bug fix and backwards-compatible api improvements"?
> >
> > Is it something else?
> >
> > Keep in mind that users out there could well be expecting something
> > semver-ish... as that is a meme that seems to me to be catching on...
> >
> > FYI: If the consensus view is different from `"backwards-compatible bug
> > fixes" only` then there is no point in pursuing my plan of weekly checks
> > for a new patch release and cutting such a release if it is releasable,
> and
> > I will drop them (we can keep the tooling I have put in place as it will
> > help improve our quality... and I intend improving that tooling anyway).
> > But if the consensus is that patch/incremental versions should be
> > `"backwards-compatible bug fixes" only` then I see no good reason why we
> > should hold onto those fixes any longer than a week after they have been
> > committed. New features can go straight into the 3.3.x branch and I (and
> > others) can cherry pick the fixes from the 3.3.x branch back to 3.2.x and
> > cut those releases when they are ready. (Which was what I thought my
> > proposal was... but re-reading I ack that it was not as obvious to the
> > reader as it was to the writer ;-) )
> >
> > -Stephen
> >
> >   [1]: http://semver.org/
> >
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: What is in a version? (was Towards faster releases)

Posted by Anders Hammar <an...@hammar.net>.
Thanks for bringing this up, Stephen!

My +1 goes to "backwards-compatible bug fixes (only)" in a bugfix/patch
release.
If we could decide (whatever we decide) what changes goes into what sort of
release, I think that would help the community a lot. I personally think
that re-using somehting like semver would be very good and in the spirit of
Maven's theme of best-practices. However, I fully appreciate that opinions
on "best-practice" in this case could be different than mine.

I also fully agree with Jason on how things work with larger companies,
where upgrading something like Maven is a big process. So if we have bugfix
releases where we carefully introduce on fixed for known bugs, I think this
would be very good and simplify that process.

Also, out of a PR perspective, I think that increasing the minor version
when we add new functionality (doesn't have to be from a user perspective
but could be technical) is good. It shows that Maven is moving forward.

/Anders


On Wed, Feb 19, 2014 at 10:22 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> I think we have a bit of a disagreement about what changes should be going
> into different version numbers.
>
> To my mind, we should be using the convention that most people expect, i.e.
> semver[1]-ish. I am not saying that we need to be super-strict in following
> the exact semver specification, but I do think that we should be following
> the semver spirit:
>
> Given a version number MAJOR.MINOR.PATCH, increment the:
> > MAJOR version when you make incompatible API changes,
> > MINOR version when you add functionality in a backwards-compatible
> manner,
> > and
> > PATCH version when you make backwards-compatible bug fixes.
>
>
> So with the above principle, the only changes that should be going into the
> 3.2.x line should be backwards compatible bug fixes.
>
> Adding functionality should be going towards 3.3.x
>
> And the modelVersion 5.0.0 stuff should be going towards 4.0.x
>
> If I look at the issue tracker for 3.2.2:
>
> http://jira.codehaus.org/issues/?jql=fixVersion%20%3D%20%223.2.2%22%20AND%20project%20%3D%20MNG
>
> I currently see 9 issues:
>
> Improvements: MNG-5589, MNG-5587, MNG-5577, MNG-4715, MNG-1958
> Bug fixes: MNG-5552, MNG-5475, MNG-5219, MNG-3559
>
> If we accept the principle that only bug fixes should be going into
> patch/incremental releases then those 5 improvements are out of scope for
> 3.2.x
>
> If we dig a bit further:
>
> * MNG-5552's fix involves extending the API, so that would be 3.3.x
> * MNG-5474 may introduce regressions if there is anyone depending on the
> current behaviour, so that could be seen as 3.3.x
>
> So my aim of faster releases becomes as soon as we get a fix for either
> MNG-5219 or MNG-3559 committed on the 3.2.x release line... then we should
> consider cutting a release of that line.
>
> That is the context in which I am suggesting that we could move to faster
> releases...
>
> Now there is a big *if* that I ack was my implicit unstated understanding
> when I started the "Towards faster releases" thread... namely that:
>
>     A Patch/Incremental version is backwards compatible bug fixes only. No
> additional functionality. Additional functionality goes in a new minor
> version.
>
> I think the resistance to my suggestion from Jason is either from a
> different world view on what should go into a patch/incremental version...
> or perhaps just forgetting that the scope of patch/incremental versions is
> what I suggest it is.
>
> So my question to the Maven developers is this:
>
> What types of things should be eligible for a patch/incremental release of
> Maven?
>
> Is it "backwards-compatible bug fixes" only?
>
> Is it "backwards-compatible bug fixes and api improvements"?
>
> Is it "any bug fix and backwards-compatible api improvements"?
>
> Is it something else?
>
> Keep in mind that users out there could well be expecting something
> semver-ish... as that is a meme that seems to me to be catching on...
>
> FYI: If the consensus view is different from `"backwards-compatible bug
> fixes" only` then there is no point in pursuing my plan of weekly checks
> for a new patch release and cutting such a release if it is releasable, and
> I will drop them (we can keep the tooling I have put in place as it will
> help improve our quality... and I intend improving that tooling anyway).
> But if the consensus is that patch/incremental versions should be
> `"backwards-compatible bug fixes" only` then I see no good reason why we
> should hold onto those fixes any longer than a week after they have been
> committed. New features can go straight into the 3.3.x branch and I (and
> others) can cherry pick the fixes from the 3.3.x branch back to 3.2.x and
> cut those releases when they are ready. (Which was what I thought my
> proposal was... but re-reading I ack that it was not as obvious to the
> reader as it was to the writer ;-) )
>
> -Stephen
>
>   [1]: http://semver.org/
>