incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: [DISCUSS] Significance of Artifact Names
Date Thu, 05 Jan 2017 02:19:35 GMT
Huge +1 to what Cédric has said.


On Wed, Jan 4, 2017 at 6:20 AM, Cédric Champeau
<> wrote:
> Cross-posting since I missed this topic in the first place. My apologies
> for the duplicate:
> I would argue that one of the Foundation mottos is "community first". In
> that sense, enforcing a policy like that is not thinking about users. It's
> adding a burden they don't care about. I am strongly against anything that
> enforces technical requirements where there shouldn't be. Enforcing Maven
> coordinates, or enforcing a _version string_ is going too far into the
> technical details. There's branding and there's technical. Maven already
> makes the mistake of mixing how you build the project and how you consume
> it, which is the root of a lot of pain. Let's not make the error again at
> the policy level, it's a total non sense.
> The Foundation can host a variety of different projects, from new ones
> written in C to "old" ones written in Java, and all the different things we
> can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_
> you consume a project, by Maven coordinates or version string is an
> implementation detail. Branding the project is not. In other words, as long
> as your package name, maven artifacts, Docker images, ... do not infringe
> copyright, it's a no brainer. However, the project page *must* state about
> incubating status and *explain* what it means. A *lot* of people don't care
> what *incubating* means in the Foundation sense (and even worse, podling
> can have very negative image). It would have been terrible for Groovy to
> change the way people consume the artifacts, making them think of low
> quality software, because they don't understand what "incubating" mean. To
> me it sounds even worse than "alpha". Since "incubating" is meant towards
> *incubating project in the sense of the Apache community*, it should *only*
> appear where it makes sense: DISCLAIMER, web site, ... That is to say
> everywhere you can give an explanation about its meaning. It should also
> appear in the source package name, because that is what we legally care
> about. But the version *string*, inside the package, is purely, again,
> internal details, just like package name, Maven coordinates, NPM
> coordinates, ... Why would you force me to use a version pattern if what I
> want is the revision hash as the version number? The policy should NOT
> impact how we design software or how we want the design to be. There are
> potential technical issues with putting such a label in a version string
> (OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to
> name the Java ecosystem), so to me enforcing the policy here is just an
> error.
> As for Groovy and the Codehaus package and Maven coordinates, we plan to
> change this in a major, breaking, 3.0 release, not before. Because it would
> be a breaking change, and some dependency management engines, typically,
> are very poor when it comes to dependency substitution, which would add too
> much burden for people to upgrade. We had an agreement with Ben from
> Codehaus to use the name when we joined the ASF.
> 2017-01-04 6:24 GMT+01:00 Alex Harui <>:
>> Sorry for top-posting.
>> It's always been interesting to me that the ASF says that it only releases
>> source code, but still has policy about the contents of convenience
>> binaries such as [6].  So, I suppose the ASF could dictate naming of
>> binary packages.
>> I know very little about Maven, but in my mind, the -incubating suffix is
>> supposed to help warn the customer or cover the ASFs butt or both.  I
>> don't know if anybody actually points to a source artifact from Maven, but
>> if the downstream user is being careful enough to work from sources, it
>> makes sense to me to put in an additional warning by adding the
>> -incubating suffix to the source package. It says that these source
>> packages are not like other ASF source packages without having to open the
>> package.
>> But for a binary artifact, given that the ASF already thinks it isn't
>> audit-able and thus not an official release, does the customer care that
>> the artifact may not be ASF-grade (especially if the artifacts were
>> already considered open before entering Apache)?  Do they really need
>> early warning?  Would it really affect the ASF if something bad was later
>> found in a binary artifact?
>> IMO, the answer to all 3 questions is no.  I don't know how hard it is to
>> suffix the source artifact with -incubating but not for the binary
>> artifacts.  But if it is hard, could the next version of Maven do it?
>> Also, if someone is concerned enough about the licensing of the artifacts
>> they depend on to go digging through all of the poms of their binary
>> dependencies, wouldn't they check the <license> section of each POM?
>> According to [7] there is a comments section there.  Could incubating
>> podlings be required to make it clear in the <license> section that this
>> thing may not be fully ASF compliant instead of having to add a suffix to
>> the version of their binary artifacts?
>> My 2 cents,
>> -Alex
>> [6]
>> [7]
>> On 1/3/17, 7:19 PM, "John D. Ament" <> wrote:
>> >All,
>> >
>> >This is a follow up to recent threads, purposely made a bit broader to
>> >encourage more discussions.  First to set down some facts about what's
>> >been
>> >established:
>> >
>> >1. Incubator policy [1] states that a podling's release meets two
>> >requirements, include "incubating" in the release archive's file name and
>> >the standard disclaimer within the documentation or README.
>> >
>> >2. The foundation policy on a valid release [2] seems to indicate that the
>> >elements that make up a valid release includes properly licensed source
>> >code, ICLAs on file, IP clearance and grants.
>> >
>> >3. Back in 2008 [3] it was established that incubator released are
>> >endorsed
>> >while the podlings themselves are not endorsed.  This means that while the
>> >podling may not fully be developed in an open way, all releases produced
>> >are expected to comply with ASF policies.
>> >
>> >So why am I harping on this problem?  The incubator has a series of
>> >guides,
>> >which are partially treated as policy and partially treated as advice.
>> >Many of these guides remain with large notions of being draft only, not
>> >finalized, I want to try to get these draft documents finalized so that
>> >we're able to provide better guidance to podlings coming in.
>> >
>> >I also think its important to keep our policies and guides as light as
>> >possible.  There shouldn't be a lot different in the incubator than a TLP
>> >would go through, or else this makes the eventual transition to TLP harder
>> >since many things previously done are now different.
>> >
>> >One of the distinguishing marks within the incubator is the use of maven.
>> >The incubator has a best practice that says if your build tool is maven,
>> >if
>> >and when you publish a convenience binary, that convenience binary must
>> >include either incubator or incubating in the version string [4].  Its not
>> >clear why maven is singled out, probably because it was the first of its
>> >kind, other tools didn't exist.  One of the key notes I can find is that
>> >the downstream redistribution channels are operated outside the ASF [5].
>> >So while Maven is an apache project, maven central is not an ASF managed
>> >resource but we are attempting to enforce our internal concerns to an
>> >outside party.
>> >
>> >So I move that we cannot apply our policies on third parties, and
>> >artifacts
>> >distributed in maven central from our release archives need not comply
>> >with
>> >our policies.
>> >
>> >John
>> >
>> >[1]:
>> >
>> >[2]:
>> >[3]:
>> >
>> 83a6fea
>> >
>> >[4]:
>> >
>> >[5]:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message