incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: [VOTE] Drop incubating requirement of Maven artifacts
Date Tue, 03 Jan 2017 12:45:48 GMT
2017-01-03 13:41 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com>:

> 2017-01-03 13:38 GMT+01:00 Cédric Champeau <cedric.champeau@gmail.com>:
>
> > +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.
> >
> >
> @Cédric: incubator is not about code maturity so still think it makes sense
> (but agree for very big projects - by users - like groovy which are widely
> used already it is weird so can be the exception confirming the rule?)
>
>
Yes but the problem is that "incubating" carries the concept of maturity.
So I was ok to have it in the source zip file name, because that is the
reference that the ASF cares about, legally speaking. But Maven
coordinates, including the version string, should not be affected by this
policy. In other words, the requirement should not leak into technical
aspects of consuming an artifact.


>
> > 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>
> > > >
> > >
> >
>

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