On Jan 3, 2017 7:06 AM, "Guillaume Laforge" <glafo...@gmail.com> 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. Wade
