-1 I use maven all the time and I'd like to know if an artifact was in the incubator or not due to a bunch of reasons listed above. Namely, it might not get out of the incubator and end up else where, incomplete release process and dependencies etc. I would agree with the prior post and suggest that other non maven artifacts should instead be aligned with maven. That said I would agree that maybe it shouldn't be in the version and instead in the classifier or similar.
Tom On Tue, Jan 3, 2017 at 11:55 AM, 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 > > > > > > > > > > > > > > -- Tom Barber CTO Spicule LTD t...@spicule.co.uk http://spicule.co.uk @spiculeim <http://twitter.com/spiculeim> Schedule a meeting with me <http://meetme.so/spicule> GB: +44(0)5603641316 US: +18448141689
