I think the fundamental problem here is that we (i.e. maven developers) do not have a shared understanding of how we want to use version numbers.
There are a group of people who want to use semantic versioning such that the major version is only incremented for "breaking" changes, minor version for "enhancements" and "patch" version for "bug fixes". There is another group of people who want to use the major version to indicate the Maven release line that the plugin targets... as that is a hard breaking change, the minor version for "enhancements" that may require changes to your pom (i.e. soft breaking since to update the plugin you have to change the pom anyway) and the "patch" version for "bug fixes" and "opt-in enhancements" We cannot keep both of these groups happy without spinning our wheels. The next release of surefire will break backwards compatibility (because it drops support for Maven 2.x) so it's going to get called 3.x.y We would like not to end up with Surefire 4.x.y before Maven 4.x, thus the people who stick to strict semver will want to roll all the breaking changes into 3.0.0 because any additional breaking changes would force a 4.0.0 (which the people who want to use the major version number to indicate Core release line would object to) My vote is that we should just say we are not using SemVer. Plugins use a scheme whereby: * Major version is minimum Core release line required to run the plugin * Minor version indicates that you may have to change your pom.xml configuration * Patch version should just be better (and don't assume the first release will be 0, because failed release votes should bump the patch like we do for core.) This would unblock us here (i.e. these would not be milestones) and anything that stops us seeing a x.y.0 release as special and thus causing us to hold back until it's ready is a bad thing IMHO *BUT* with all that said, whoever is running the release gets to call the version number. Unless someone other than Tibor steps up and cuts a release we have to put up with the version number he decides... but any committer at any time could step up and cut a release and call a vote (just respect to the community norms stops people "stealing" the release manager role from someone who is holding it) On Wed, 13 Nov 2019 at 12:31, Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > To my thinking, a release candidate is believed to be done. All > features are complete and no unshippable bugs are known. An RC is > posted to give users a chance to shake out any unknown bugs. If no > unknown bugs are found then the RC is the release, module a version > change. > > A milestone, by contrast, is a step on the way and is definitely not > feature complete. > > The way you're describing Maven's milestone releases they sound like > the outcome of a big bang release process. There are certain features > that have to go in to a milestone, and the product won't ship until > they're done. Only, some features and bug fixes are needed before then > so you ship the product anyway and call it a milestone. It's a bit of > a wishy washy middle ground. > > As a user I find this scheme confusing. I'd prefer a more > straightforward versioning scheme: if it's ready for end users then > there's no classifier, just 3.0.0, 3.0.1, 3.1.0, etc. If it's not call > it 3.1.0-beta or some such. It doesn't make a big difference to the > code that gets shipped when, just how it's labeled for end users. > > As a developer I definitely prefer to release features and bug fixes > sooner rather than later. I also find smaller, more frequent releases > a lot easier to manage than once a year big bang releases. As long as > the external facing API is stable--in the case of Maven this > essentially means the syntax of the pom.xml file--there's no reason > not to ship with every significant improvement. If you're planning on > 10 improvements in a product, and two are done, ship it, assuming none > of the remaining eight are going to break anything incompatibly. Ths > does assume the release process is automated and lightweight, but > that's a good thing to have in any case. > > On Tue, Nov 12, 2019 at 10:21 PM Tibor Digana <tibordig...@apache.org> > wrote: > > > > Elliote, > > > > It is stable. We do not want to break users, but we split the global > > picture for the version Y.0.0 into multiple complete stages (not > > incomplete!), but the Y.0.0 becomes a bunch of these Mx. > > It does not mean that a bugfix is incomplete or appears across multiple > > versions. > > I think you have another view and another scope of the work in your mind. > > > > For me Mx is only a naming conventions. > > This team is calling it milestone Mx and not RCs. > > Many OSS projects are releasing RCs. Not sure why we do not. > > > > If the Wildfly project is going to cut a new major version, they release > > RC. > > For me it is a kind of "give it a try in users" and then they fix the > > realistic issues which could not be found by the integration tests. > > And then they have nice version. Somebody can still use the RC and he > will > > never see a bug because not everybody is using different versions of > > JMS/Artemis publisher and subscriber. > > > > So the model can be anything but this model does not mean that we want to > > intentionally break the users. > > We can propose more alternatives and finally the result will be naming > > conventions, when/how to use them.... > > > > T > > > > On Tue, Nov 12, 2019 at 1:01 PM Elliotte Rusty Harold < > elh...@ibiblio.org> > > wrote: > > > > > I'm a little nervous about this is being messages to and being > > > understood by developers. How stable is a milestone release? If it's > > > not stable, they shouldn't be seeing as abroad an adoption as they > > > are. If it is stable, then why not give it a full release as 3.0.0. > > > (or whatever) and add more in 3.1.0, 3.2.0, etc.? > > > > > > On Tue, Nov 12, 2019 at 6:51 AM Tibor Digana <tibordig...@apache.org> > > > wrote: > > > > > > > > Hi Elliotte, > > > > > > > > I am also using milestones in Surefire, as you may have noticed, > because > > > > the complete work is too big and for one release. > > > > As for instance, milestones are fantastic for the major versions > like in > > > > 3.0.0 because it is the only chance when you can break some backwards > > > > compatibility in plugin configuration. > > > > That's our case. For instance the system properties for config > parameters > > > > of plugins share the same because they do not have prefixes. So i > put the > > > > prefix in the system property and that's what i break, a little. It > was > > > > just an example, but this is the principle that i understand and we > > > > untilize it in the milestones. > > > > > > > > T > > > > > > > > On Mon, Nov 11, 2019 at 7:55 PM Elliotte Rusty Harold < > > > elh...@ibiblio.org> > > > > wrote: > > > > > > > > > What is the significance of the M2/M3 classifier in the version > > > > > string? It's not obvious to me whether this is a release version or > > > > > not. > > > > > > > > > > Is there a reason not to call this simply 3.0.0 or 3.0.1? > > > > > > > > > > On Mon, Nov 11, 2019 at 1:50 PM Karl Heinz Marbaise < > khmarba...@gmx.de > > > > > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I've seen there are a lot of fixes in the meantime in the current > > > state > > > > > > so I would like to cut a release and the end of the week. > > > > > > > > > > > > So if someone has any objections please raise your hand. > > > > > > > > > > > > Kind regards > > > > > > Karl Heinz Marbaise > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > -- > > > > > Elliotte Rusty Harold > > > > > elh...@ibiblio.org > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
