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 > >
