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:52:41 GMT
2017-01-03 13:45 GMT+01:00 Cédric Champeau <cedric.champeau@gmail.com>:

> 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.
>
>
Think most of maven users will never grab the source zip and don't even
care so it is important to still reflect this maturity issue in what they
use (+ it is consistent since we release a single version and not 2: one
for legal and one for user)


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