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 <aha...@adobe.com>: > 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] https://www.apache.org/legal/src-headers.html#faq-binaries > [7] https://maven.apache.org/pom.html#Licenses > > On 1/3/17, 7:19 PM, "John D. Ament" <johndam...@apache.org> 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]: > >http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > >[2]: http://www.apache.org/dev/release-publishing.html#valid > >[3]: > >https://lists.apache.org/thread.html/0b6c065a908c5f9ec39fa78c31b39c > 83a6fea > >29eb34fada0ee070413@1222432864@%3Cgeneral.incubator.apache.org%3E > >[4]: > >http://incubator.apache.org/guides/release-java.html#best-practice-maven > >[5]: http://www.apache.org/dev/release-distribution.html#channels > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
