Re: Maven Enforcer Release-3.0.0-M3

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven Enforcer Release-3.0.0-M3

Elliotte Rusty Harold
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]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Enforcer Release-3.0.0-M3

Tibor Digana
i forgot to say that the work in Surefire splits to multiple Mx which are
dependent.
so the milestones are useful for the Surefire, IMO.
not sure how about in the oher plugins,, enforcer, release plugin, etc. but
they may have different visions with the releases.

On Wed, Nov 13, 2019 at 3:26 PM Tibor Digana <[hidden email]> wrote:

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