not sure how about in the oher plugins,, enforcer, release plugin, etc. but
> I think i can see the complexity the best in Surefire. That's why we have
> these milestones because finally we have to break some compatibility in
> order to fix the bugs.
> Let me pls explain why.
>
> The thing is that we are in the situation where we cannot fix the bugs
> without changing e.g. the API for Provider (minimum change the best) and
> more other things:
> 1. Also we cannot fix another issues with reports without changing the
> interface in StatelesXmlReporter.
> 2. The issues for OSGi f/w and Arquillian can be fixed if we use TCP/IP
> between processes and this required breaking public methods, provider impl,
> listeners impl, etc.
> 3. And the users want to use fully-qualified classes for the test filters
> instead of "/org/abc/MyTest.java" which break the config parameters and we
> want to expose the Test List Processor in an extension because this will
> save our time in JIRA.
> 4. Finally, we want to use prefixes for the config properties which avoids
> conflicts with another plugins, and this breaks user propertis but not all
> of them.
>
> So yes, we are doing bug fixes, a lot, and we break internal code which is
> a fix for annoying bugs.
> We are in the loop of bugfixing and changing the code + API a bit more
> than usually in the normal releases.
> And we pay an attention to not to break the users in the first milestones,
> that's the best rule.
>
> The external implementators will notice that yes the Providers changed and
> there was a reason in 3.0.0.
> Finally, the last milestone will break the backwards compatibility in the
> configuration but not in the beginning where the users do not expect it. So
> therefore there it must be a clear plan with the changes in road map
> staring from inside code to finaly outside (means configuration). And this
> cannot be done in one step. It is perhaps not ideal with Mx, but the
> reality is that this is big legacy code and quite feasible. All the users
> will be happy with all these fixes and extensions. So it is also worth to
> have a feedback from the users during the work. And it is maybe better to
> have one major release after long time than breaking it into very frequent
> major releases with 4.0, 5.0, 10.0 unexpectedly changing the external API
> too often.
>
>
> On Wed, Nov 13, 2019 at 2:46 PM Stephen Connolly <
>
[hidden email]> wrote:
>
>> Oh I forgot, Surefire further complicates things as it has an API that
>> needs to be implemented by providers, so we need to try and encode that
>> API's breaking changes into our version number also... a lot of stuff to
>> try and encode in a version number... I fear semver is not up to the job
>>
>> On Wed, 13 Nov 2019 at 13:44, Stephen Connolly <
>>
[hidden email]> wrote:
>>
>> > 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 <
[hidden email]
>> >
>> > 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 <
[hidden email]>
>> >> 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 <
>> >>
[hidden email]>
>> >> > 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 <
>>
[hidden email]>
>> >> > > 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 <
>> >> > >
[hidden email]>
>> >> > > > 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 <
>> >>
[hidden email]
>> >> > > >
>> >> > > > > 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:
[hidden email]
>> >> > > > > > For additional commands, e-mail:
[hidden email]
>> >> > > > > >
>> >> > > > >
>> >> > > > >
>> >> > > > > --
>> >> > > > > Elliotte Rusty Harold
>> >> > > > >
[hidden email]
>> >> > > > >
>> >> > > > >
>> >> ---------------------------------------------------------------------
>> >> > > > > To unsubscribe, e-mail:
[hidden email]
>> >> > > > > For additional commands, e-mail:
[hidden email]
>> >> > > > >
>> >> > > > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Elliotte Rusty Harold
>> >> > >
[hidden email]
>> >> > >
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail:
[hidden email]
>> >> > > For additional commands, e-mail:
[hidden email]
>> >> > >
>> >> > >
>> >>
>> >>
>> >>
>> >> --
>> >> Elliotte Rusty Harold
>> >>
[hidden email]
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail:
[hidden email]
>> >> For additional commands, e-mail:
[hidden email]
>> >>
>> >>
>>
>
Locked
