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. 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. On Tue, Jan 3, 2017 at 12:55 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > -1, I think it is important to show that the artifact dependency is not > stable and should be used as such (if the project never graduates, even if > code is very mature then you still get all the troubles you can think > about). > > Question is IMHO the opposite: why others don't follow the -incubating rule > as well? > > PS: of course an alternative to follow maven common practise would be to > put incubating in the groupId instead of version but in practise we have > more easily a placeholder for the version than the groupId so I still think > version is the easiest place for users. Also note no user complained about > that excepted about the fact it denotes a lack of maturity which is exactly > the purpose AFAIK. > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/ > rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2017-01-03 12:50 GMT+01:00 Myrle Krantz <mkra...@mifos.org>: > > > +1 non-binding > > > > If a best practice targets only maven and not the others, wouldn't that > be > > a reason for a podling to consider avoiding using maven to distribute > > binaries at all? Is it fair for Apache to disadvantage maven that way? > > > > Can Apache enforce policies about binaries not released under the Apache > > name? Wouldn't that sort of policy be in contradiction to the Apache > > license? > > > > Keeping a best practice which is not only unenforceable and inconsistent, > > but also disadvantageous to any project which tries to follow it, > > discredits other best practices as well. (Broken windows theory) > > > > Greets from Germany > > Myrle > > > > > > On Tue, Jan 3, 2017 at 12:34 PM, John D. Ament <johndam...@apache.org> > > wrote: > > > > > Carsten, Julian, > > > > > > I want to reiterate my notes from a prior message [1] in case there is > > any > > > confusion over the ask. There is a "best practice" around maven > specific > > > releases that has been treated as policy, [2]. This best practice for > > > some reason is only applied if you are using the maven build tool. > E.g. > > > published python packages, ruby gems do not have this requirement. The > > > purpose of this thread is to realign maven specific releases with the > > other > > > convenience binaries published by podlings. > > > > > > This is not intended to drop the -incubator/-incubating tag applied to > > > source releases. It was however established in 2008 [3] that releases > > > published by the incubator were endorsed, the -incubator/incubating tag > > was > > > to imply that the project itself was not considered stable and could go > > > away. > > > > > > John > > > > > > [1]: > > > https://lists.apache.org/thread.html/c6daddf2d564685acdcd14a876bebf > > > 392b25c268905b353e36b3cac5@%3Cgeneral.incubator.apache.org%3E > > > [2]: > > > http://incubator.apache.org/guides/release-java.html#best- > practice-maven > > > [3]: > > > https://lists.apache.org/thread.html/0b6c065a908c5f9ec39fa78c31b39c > > > 83a6fea29eb34fada0ee070413@1222432864@%3Cgeneral.incubator.apache.org > %3E > > > > > > > > > On Tue, Jan 3, 2017 at 1:47 AM Carsten Ziegeler <cziege...@apache.org> > > > wrote: > > > > > > > -1 > > > > > > > > I followed the "other thread" but it's still unclear to me what real > > > > problem this tries to solve. > > > > As others noted, there should be an indicator whether this is already > > an > > > > official Apache project or in the incubator and adding it to the > > version > > > > information is the solution with causes the least amount of pain for > > > > users. It's a simple marker, clearly visible for any user. > > > > And once the project is out of the incubator, users simply need to > > > > update to a new version - something which they would do anyway. > > > > > > > > Carsten > > > > > > > > John D. Ament wrote > > > > > All, > > > > > > > > > > I'm calling to vote on a proposed policy change. Current guide at > > [1] > > > > > indicates that maven artifacts should include incubator (or > > incubating) > > > > in > > > > > the version string of maven artifacts. Its labeled as a best > > practice, > > > > not > > > > > a requirement and is not a policy followed on other repository > > > management > > > > > tools (e.g. PyPi). > > > > > > > > > > I therefore push forward that the incubator will cease expecting > > > > java-based > > > > > projects to publish artifacts with "-incubating" in the version > > string, > > > > > with the understanding that: > > > > > > > > > > - Incubating is a term used to refer to a project's stability, not > a > > > > > release's stability. It is generally understood that incubating > > > projects > > > > > are not necessarily immature, but may have a potential of failing > to > > > > become > > > > > a TLP. > > > > > - Podling releases are endorsed, the podling itself is not > endorsed. > > > We > > > > > will not approve releases that are blatantly against ASF policies. > > > > > > > > > > > > > > > [ ] +1 Drop the -incubator/-incubating expectation of maven > projects > > > > > [ ] +/0 > > > > > [ ] -1 Don't drop because.... > > > > > > > > > > > > > > > [1]: > > > > > http://incubator.apache.org/guides/release-java.html#best- > > > practice-maven > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Carsten Ziegeler > > > > Adobe Research Switzerland > > > > cziege...@apache.org > > > > > > > > ------------------------------------------------------------ > --------- > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > -- Guillaume Laforge Apache Groovy committer & PMC Vice-President Developer Advocate @ Google Cloud Platform Blog: http://glaforge.appspot.com/ Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>
