Maven Enforcer Release-3.0.0-M3

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

Maven Enforcer Release-3.0.0-M3

Karl Heinz Marbaise-3
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]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Enforcer Release-3.0.0-M3

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

Reply | Threaded
Open this post in threaded view
|

Re: Maven Enforcer Release-3.0.0-M3

Tibor Digana
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 <[hidden email]>
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
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>