maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject What is in a version? (was Towards faster releases)
Date Wed, 19 Feb 2014 09:22:12 GMT
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

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

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

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

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 ;-) )



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message