+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 <[email protected]>: > 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/ > > > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! nbsp;! >
