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
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
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
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
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
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,
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
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
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
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
Il mar 12 nov 2019, 13:01 Elliotte Rusty Harold 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
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
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
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
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 wrote:
>
> Hi,
>
> I've seen there are a lot of
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
-
16 matches
Mail list logo
