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 < [email protected]> 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/ >
