incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [VOTE] Drop incubating requirement of Maven artifacts
Date Tue, 03 Jan 2017 12:25:06 GMT
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>
>

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