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
