incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <>
Subject Re: [VOTE] Drop incubating requirement of Maven artifacts
Date Fri, 06 Jan 2017 16:15:05 GMT
On Jan 3, 2017 7:06 AM, "Guillaume Laforge" <> wrote:

When you say "it denotes a lack of maturity which is exactly the purpose
AFAIK", what do you mean my maturity?
Maturity in terms of how well it follows Apache processes and principles?
Or in terms of "the project is not ready for prime time"?

For example, for Apache Groovy, the project was very mature, and was
already 11 years old when it joined the ASF.
It was very stable, very mature, very solid.
And it was a bit weird to append "-incubating", as people thought it meant
"not ready for prime time" rather that "going through ASF incubation".
Furthermore it forced users to also change the appId although they usually
change only the version number, which might be in some property file
externally. It's not such a big big deal, but it's still something they had
to do, which is a bit unconvenient.

Agreed, and something NetBeans will face. But, surely users of a projects
artifacts use more information than the artifact versions to decide to use
a project. Though without specific reasoning on the project site about
versioning, I have seen, even within my company, 0.x versions have a bad
connotation; Dropwizard and Nodejs.

Too this is a new classifier that the tooling will have to know about in
its RCP and plugin developer support in the case of NetBeans, which will
only be relevant during the incubation phase. Without it, the tooling would
create invalid project files, so it has impacts outside of just the build
system for projects; some code changes on relevant to incubation.

I also second the idea that such a rule should apply to all kind of
artifacts or none, but not be an exception of Maven artifacts.
It doesn't make sense to enforce a rule for just one... and hence the idea
of lifting that rule altogether for everybody.

Also agreed. If it is important for the reasons noted, then it should be
just as important every where. If the tooling of various things cannot
support it, then perhaps it isn't something worth caring about broadly, but
then is it worth it at all if that is the case?

But too, isn't this is exactly what Maven SNAPSHOTS are about? A release is
a final thing whether it has some warts or not. So, if I have a mature
project going to Apache, its released artifacts should be something I can
depend on as well as the previous released artifacts if I trusted them
regardless if the project may not make another release. If I am using that
artifact from Central, it isn't magically going away.

As the project was donated to Apache, was the same risk not already in
existence or present before? This is an inherent risk with 3rd party
dependency whether COTS or OSS which often seems lost on the industry, and
adding an extra bit to the binary artifact isn't changing that.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message