maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <>
Subject Re: What is in a version? (was Towards faster releases)
Date Wed, 19 Feb 2014 09:38:18 GMT
Thanks for bringing this up, Stephen!

My +1 goes to "backwards-compatible bug fixes (only)" in a bugfix/patch
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.


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]:

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