On 20 February 2014 21:30, Dennis Lundberg <[email protected]> wrote:
> 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. > Yep... does mean that we need to scrub the issues to ensure that issue types are correct... but we need to scrub the issues anyway > > 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. > I think we can legitimately apply a different policy for core versus plugins. For plugins the policy I would suggest is: * Maintain the latest minor release only (no backporting bug fixes to previous minor release) * Security fixes to previous minor release. * This means that we only support fixing issues one and one back for plugins, so plugins in effect are EOL once there have been two new minor releases of that plugin For core the policy I would suggest is: * Maintain the latest minor release * Maintain the previous minor release (backport bug fixes from latest minor release) * Security fixes for all previous minor releases released within the last 12 months * End of life releases older than 12 months. (because if we are not even providing security releases then it is by definition EOL) If we want to go to 24 months for security fixes that's fine by me... we should pick some time period and stick to it. -Stephen > 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/ > > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
