maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: What is in a version? (was Towards faster releases)
Date Thu, 20 Feb 2014 21:30:56 GMT
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
<> 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:
> 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]:

Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message