Maven Enforcer Release-3.0.0-M3

[Karl Heinz Marbaise <kh...@gmx.de>]

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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven Enforcer Release-3.0.0-M3

[Tibor Digana <ti...@apache.org>]

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 <ti...@apache.org> 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 <
> stephen.alan.connolly@gmail.com> 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 <
>> stephen.alan.connolly@gmail.com> 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 <elharo@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 <ti...@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 <
>> >> elharo@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 <
>> tibordigana@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 <
>> >> > > elharo@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 <
>> >> khmarbaise@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-unsubscribe@maven.apache.org
>> >> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> > > > > >
>> >> > > > >
>> >> > > > >
>> >> > > > > --
>> >> > > > > Elliotte Rusty Harold
>> >> > > > > elharo@ibiblio.org
>> >> > > > >
>> >> > > > >
>> >> ---------------------------------------------------------------------
>> >> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> > > > >
>> >> > > > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Elliotte Rusty Harold
>> >> > > elharo@ibiblio.org
>> >> > >
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> > >
>> >> > >
>> >>
>> >>
>> >>
>> >> --
>> >> Elliotte Rusty Harold
>> >> elharo@ibiblio.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>>
>

Re: Maven Enforcer Release-3.0.0-M3

[Tibor Digana <ti...@apache.org>]

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 <
stephen.alan.connolly@gmail.com> 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 <
> stephen.alan.connolly@gmail.com> 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 <el...@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 <ti...@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 <
> >> elharo@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 <
> tibordigana@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 <
> >> > > elharo@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 <
> >> khmarbaise@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-unsubscribe@maven.apache.org
> >> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Elliotte Rusty Harold
> >> > > > > elharo@ibiblio.org
> >> > > > >
> >> > > > >
> >> ---------------------------------------------------------------------
> >> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > > > >
> >> > > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Elliotte Rusty Harold
> >> > > elharo@ibiblio.org
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >
> >> > >
> >>
> >>
> >>
> >> --
> >> Elliotte Rusty Harold
> >> elharo@ibiblio.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>

Re: Maven Enforcer Release-3.0.0-M3

[Stephen Connolly <st...@gmail.com>]

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 <
stephen.alan.connolly@gmail.com> 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 <el...@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 <ti...@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 <
>> elharo@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 <ti...@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 <
>> > > elharo@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 <
>> khmarbaise@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-unsubscribe@maven.apache.org
>> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Elliotte Rusty Harold
>> > > > > elharo@ibiblio.org
>> > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > > >
>> > > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Elliotte Rusty Harold
>> > > elharo@ibiblio.org
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>>
>>
>>
>> --
>> Elliotte Rusty Harold
>> elharo@ibiblio.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

Re: Maven Enforcer Release-3.0.0-M3

[Tibor Digana <ti...@apache.org>]

Let's not mention JDK as a good example today because of:
1. almost every release was about the switch-case, and little improvement
in Lambda. Now it looks like they do not have language architect although
we know that Oracle has the architect.
2. Valhalla can be enabled in CLI but this produced incompatible bytecode,
thus two versions in one JDK. And users fire a bug against Surefire.
3. dropped feature raw-string-literals, basically unstable. This is a new
experience with Java because we trusted the Java that it would be backwards
compatible with older versions.

So JDK started with an extreme and goes to another extreme.
What changed was the transition from JCP to OSS.
So it seems that nothing is so good with jdk and frequent releases.
Simply the Java language is saturated. You won't find too many new features
in far aways future. I understand that the top management wants to have
frequent releases but the language is not capable. Another story is the JVM
because the performance and the GC is always welcome to improve more
frequently.


On Wed, Nov 13, 2019 at 9:31 PM Elliotte Rusty Harold <el...@ibiblio.org>
wrote:

> I'm hearing a lot of subtly different descriptions of what different
> developers and subprojects use the term "milestone" for.
>
> It's certainly reasonable to have a major version bump in the plugin
> and drop support for Maven 2.0. The goal that the plugin major version
> should match the Maven major version does seem to be causing some
> mishegas though.
>
> Even more problematic is the hope to finish everything on the wish
> list for a plugin before declaring a 3.0.0 release. That can leave
> users without a clearly supported, stable plugin for years. More
> incremental releases that provide additional features and bug fixes
> that are ready now would be very helpful. The JDK itself and the
> Eclipse project are two big examples of projects that have stopped
> pushing mega-do-everything releases in favor of more predictable,
> time-based release cycles. I was skeptical when they announced the
> change, but it seems to be working well. The Maven project might want
> to consider whether something similar could work for us.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Maven Enforcer Release-3.0.0-M3

[Elliotte Rusty Harold <el...@ibiblio.org>]

I'm hearing a lot of subtly different descriptions of what different
developers and subprojects use the term "milestone" for.

It's certainly reasonable to have a major version bump in the plugin
and drop support for Maven 2.0. The goal that the plugin major version
should match the Maven major version does seem to be causing some
mishegas though.

Even more problematic is the hope to finish everything on the wish
list for a plugin before declaring a 3.0.0 release. That can leave
users without a clearly supported, stable plugin for years. More
incremental releases that provide additional features and bug fixes
that are ready now would be very helpful. The JDK itself and the
Eclipse project are two big examples of projects that have stopped
pushing mega-do-everything releases in favor of more predictable,
time-based release cycles. I was skeptical when they announced the
change, but it seems to be working well. The Maven project might want
to consider whether something similar could work for us.

-- 
Elliotte Rusty Harold
elharo@ibiblio.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven Enforcer Release-3.0.0-M3

[Robert Scholte <rf...@apache.org>]

Robert Scholte: 
In case of plugins going from 2.x to 3.x is a huge step and an opportunity to break backwards compatibility.
Most important, as mentioned by Stephen, is dropping Maven 2 support.
Next, this is the best chance to remove deprecated parameters, refactoring code, etc, before we're bound to a 3.x version for a long time.
Especially the larger plugins require huge changes.
For example: I started refactoring the maven-release-plugin. Dropping Maven2 support has finished, so we should start with 3.0.x, but the intended refactoring is not ready. All integration tests still work, so it is stable. 
People start asking for releases, so what to do?
To me releasing a milestone is an acceptable solution:
- it is a 3.x, so people should be aware that it won't support Maven 2 anymore
- going from 2.x to 3.x should hint that breaking changes might have happened (although people do still send e-mails about plugins suddenly not working after upgrading, without reading release notes about changed and removed parameters)
- some are waiting for a long time for some feature, so having a milestone might help them.
- knowing that it is a milestone should make them aware there are still planned changes before releasing 3.0.0, so take extra care of parameters.

The milestone is a literal milestone: where on the right track, just haven't finished it yet.

Robert


On 13-11-2019 14:44:22, Stephen Connolly <st...@gmail.com> 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
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
> 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 <>
> elharo@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
> > > 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 <>
> > > elharo@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 <>
> khmarbaise@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-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Maven Enforcer Release-3.0.0-M3

[Stephen Connolly <st...@gmail.com>]

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 <el...@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 <ti...@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 <
> elharo@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 <ti...@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 <
> > > elharo@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 <
> khmarbaise@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-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Maven Enforcer Release-3.0.0-M3

[Elliotte Rusty Harold <el...@ibiblio.org>]

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 <ti...@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 <el...@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 <ti...@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 <
> > elharo@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 <khmarbaise@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >



-- 
Elliotte Rusty Harold
elharo@ibiblio.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven Enforcer Release-3.0.0-M3

[Tibor Digana <ti...@apache.org>]

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 <el...@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 <ti...@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 <
> elharo@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 <khmarbaise@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Maven Enforcer Release-3.0.0-M3

[Eric Lilja <mi...@gmail.com>]

I guess the reasoning goes something like this: "I am a plugin developer,
and I want to release a number of changes, a sub-set of which are "breaking
changes". Since all my changes are not ready at the same time and I want to
avoid releasing several major versions close to each other (assuming
semantic versioning is used), I use milestones, to lead up to next major".

- Eric L

On Tue, Nov 12, 2019 at 1:38 PM Enrico Olivelli <eo...@gmail.com> wrote:

> Il mar 12 nov 2019, 13:01 Elliotte Rusty Harold <el...@ibiblio.org> ha
> scritto:
>
> > 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.?
> >
>
> I totally agree with this point.
> Personally I don't like milestones as we are doing with plugins, it is very
> confusing for users.
> If the plugin is good to be used in 'production' (in every day work) than
> we should not call it -Mx.
> If we know it has problems but some user needs it we can call it 'beta'.
>
> Enrico
>
>
>
>
>
>
> > On Tue, Nov 12, 2019 at 6:51 AM Tibor Digana <ti...@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 <
> > elharo@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 <
> khmarbaise@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: Maven Enforcer Release-3.0.0-M3

[Enrico Olivelli <eo...@gmail.com>]

Il mar 12 nov 2019, 13:01 Elliotte Rusty Harold <el...@ibiblio.org> ha
scritto:

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

I totally agree with this point.
Personally I don't like milestones as we are doing with plugins, it is very
confusing for users.
If the plugin is good to be used in 'production' (in every day work) than
we should not call it -Mx.
If we know it has problems but some user needs it we can call it 'beta'.

Enrico






> On Tue, Nov 12, 2019 at 6:51 AM Tibor Digana <ti...@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 <
> elharo@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 <khmarbaise@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Maven Enforcer Release-3.0.0-M3

[Elliotte Rusty Harold <el...@ibiblio.org>]

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 <ti...@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 <el...@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 <kh...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >



-- 
Elliotte Rusty Harold
elharo@ibiblio.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven Enforcer Release-3.0.0-M3

[Tibor Digana <ti...@apache.org>]

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 <el...@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 <kh...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Maven Enforcer Release-3.0.0-M3

[Karl Heinz Marbaise <kh...@gmx.de>]

Hi Elliotte,

On 11.11.19 19:55, Elliotte Rusty Harold 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.

This is a milestone which is not finally the whole work intended to be
done for 3.0.0 which will take more time todo but the last release is a
little bit too long ago...so the -M3 release contains already fixed
issues which bothers people...just reading/hearing the community.

The final work can be done without bothering the people for issues which
already have been fixed. That make them happy.

Kind regards
Karl Heinz Marbaise


>
> 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 <kh...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven Enforcer Release-3.0.0-M3

[Elliotte Rusty Harold <el...@ibiblio.org>]

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 <kh...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


-- 
Elliotte Rusty Harold
elharo@ibiblio.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org