Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CACLE=7MerVW=JSXKaM+ZLFiLAcYOEUke+CP8Ox3OEHptVN-GZg@mail.gmail.com>
References: <CAOqetn-JB7fiih84fpZVHVWu4Da=jx3B4sOS+gQPHHQOYxHASw@mail.gmail.com>
 <f72b3913-af37-2530-b0d7-861a2e3a4e49@apache.org> <CAOqetn_rN6AwtPMQ5nzpDTM_Ti9aGYzYAJj0Dw3e9Qt0K0=A0Q@mail.gmail.com>
 <CAKkaEgAj4_AtdhOW0bhi50As9GQ69GXtwW5CVVk1XM1kS1oZAg@mail.gmail.com>
 <CACLE=7OKByQLiy8xvJKgPaexsb92s2FGzJXudO7EGtaVmuLVjA@mail.gmail.com>
 <CAJ2HCd9+N1T17_jQU6KWw6u1TCL4pjz0u4iCBOSdLMuRQSzVSg@mail.gmail.com> <CACLE=7MerVW=JSXKaM+ZLFiLAcYOEUke+CP8Ox3OEHptVN-GZg@mail.gmail.com>
From: =?UTF-8?Q?C=C3=A9dric_Champeau?= <cedric.champeau@gmail.com>
Date: Tue, 3 Jan 2017 13:38:53 +0100
Message-ID: <CADQzvmmC536KK+ZLS0gsrdNmNVm=fpaYfUCWeJgzkL+GpdaddQ@mail.gmail.com>
Subject: Re: [VOTE] Drop incubating requirement of Maven artifacts
To: "general@incubator.apache.org" <general@incubator.apache.org>
Content-Type: multipart/alternative; boundary=001a113cdcaa7b3bbb05452ff3dc
archived-at: Tue, 03 Jan 2017 12:39:17 -0000

--001a113cdcaa7b3bbb05452ff3dc
Content-Type: text/plain; charset=UTF-8

+1

Note that for Groovy, the source artifact, which is what legal is all
about, contained the -incubating appendix. The Maven artifacts did not, and
I think it's a reasonable thing: people were used to stable versions of
Groovy for years, there was no reason why a new one wouldn't be.

2017-01-03 13:25 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com>:

> 2017-01-03 13:06 GMT+01:00 Guillaume Laforge <glaforge@gmail.com>:
>
> > 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.
> >
> >
> And that is exactly this. Don't get me wrong, I'm part of several
> incubating projects and I don't like to have -incubating cause it looks not
> mature where sometimes code is very robust...but the project is immature -
> otherwise it wouldn't be in incubator. Even for groovy, there were few
> chances but still some, it doesn't match ASF and it could have moved
> somewhere else which is a stability issue which is important to show in the
> published artifacts.
>
> Not sure I get the appId since most incubator projects don't reflect the
> state in the groupId but only the version for this exact reason (make user
> upgrade from incubator to TLP just a version to change and not all
> coordinates - which makes the classifier as bad as the groupId and version
> a good compromise).
>
>
> > 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 <
> rmannibucau@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 <mkrantz@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 <
> johndament@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 <
> > cziegeler@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
> > > > > > cziegeler@apache.org
> > > > > >
> > > > > > ------------------------------------------------------------
> > > ---------
> > > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail: general-help@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>
> >
>

--001a113cdcaa7b3bbb05452ff3dc--