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/0b6c065a908c5f9ec39fa78c31b39c83a6fea >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
