> I would favor a system of marker(s) indicating the code maturity (incl legal)
There is no standard afaik to indicate legal or community 'maturity'. It would be something for a (RDF) vocabulary for artifacts to be adopted industry wide. Right now none of the Maven coordinates are a good fit for such markers. The world uses version numbers to indicate code maturity from a technical pow. If somebody cares about the legal aspect they look at the project license, dependencies, website, project owner good standing, etc. --emi On Fri, Jan 6, 2017 at 2:37 AM, Niclas Hedhman <nic...@hedhman.org> wrote: > Coming late to the party... > > This has been discussed, and contentious, since "forever". A long time ago, > there was a notion that a podling release was not an ASF release (which was > the main reason for the "incubating" marker in all release and support > artifacts. But that pendulum has swung in the opposite direction, and > podling releases are now expected to be at ASF TLP levels. > > Pierre pointed out that "incubating" refers to community and not code, but > we don't release a community, we release code. I think this is an important > fact. > > So, instead of tying the "incubating" marker to "incubating", I would favor > a system of marker(s) indicating the code maturity (incl legal). So, for a > podling release to be 1.2.3 (a la Groovy), the same release standard as > TLPs are applied, but allow "alpha", "rc" or similar markers for podlings > to "practice" releases. Probably not pushing those to mirrors, but > otherwise identical in "process" for podling to get their grips on the > release process. > > So, I am +1 with John's "something is broken" observation, although I also > agree with the many "-1"s that think there is value to the public here. > > > Cheers > > On Wed, Jan 4, 2017 at 7:47 PM, John D. Ament <johndam...@apache.org> wrote: > >> I'll point out that this is a cancel thread..., I'm fine if people want to >> continue chatting in here, but I started a new discussion on >> https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0f >> d0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E >> >> I'll try to answer questions I saw pop up >> >> Mark Struberg: No, ignoring commons/log4j for a minute, other projects >> continue to work under legacy maven coordinates. Includes one i already >> linked to - groovy, also freemarker, zest/polygene (a project that went >> straight to TLP). There's neither foundation policy nor legal impact by >> using other very similar marks, especially when the project's name hasn't >> changed. Publishing under "com.oracle.someProduct" would probably be bad >> from a marks standpoint since it shows as property of some other company, >> whereas former foundations or completely independent projects. Plus, the >> way maven central works you own the entire tld, except for cases where its >> a known third party publisher. For instance, I own (personally) the domain >> name ament.ws and have access to publish under maven coordinates >> ws.ament.*. Github users have to request io.github.themselves manually. I >> assume that something similar exists between the ASF and Sonatype to enable >> publishing under org.apache, and ensure that no one else can use >> org.apache. >> >> Pierre Smits: This is something I expected to be a hot topic. So while >> 100% consensus isn't expected, a clear path forward is something to expect, >> even if not everyone is happy about the outcome. FWIW, there seem to be 3 >> different POVs (that I could identify) on those who were against the idea: >> >> - Those who thought this was dropping -incubating from the Apache release >> archive. >> - Those who acknowledged that this was maven specific and felt it should >> continue as is. >> - Those who acknowledged that this was currently maven specific and should >> be made broader. >> >> John >> >> >> On Wed, Jan 4, 2017 at 4:49 AM Martijn Dashorst < >> martijn.dasho...@gmail.com> >> wrote: >> >> > Late to the party, but having a long think about this is sometimes >> > beneficial. >> > >> > +1 to drop the -incubator/-incubating version attachment for any >> > artifacts (not just Maven). >> > >> > My reasoning is the following: >> > >> > Source code lives longer than any community. Long after a podling has >> > gone through the incubator, the code remains. The releases remain. How >> > a community conducts itself doesn't reflect on the released code. Code >> > just exists. >> > >> > While it is important for current users coming to a project to know >> > the status of the community, does it really matter if the code is in >> > incubation or has graduated? Does that matter in 5 years whether the >> > code of foo-1.2 was incubating while the community has graduated and >> > now resides in the attic? >> > >> > Releases have a long life. Code has a long life. We shouldn't mix >> > timely things like project status with long lived things like >> > releases. Websites are examples of timely, short lived documents and >> > incubation status is a (relatively) short lived state in the long >> > lives of projects. We shouldn't burden the long lived artifacts with >> > the orthogonal status of a project. >> > >> > Martijn >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Jan 2, 2017 at 6:22 PM, John D. Ament <johndam...@apache.org> >> > 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 >> > >> > >> > >> > -- >> > Become a Wicket expert, learn from the best: http://wicketinaction.com >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> > >> > >> > > > > -- > Niclas Hedhman, Software Developer > http://polygene.apache.org <http://zest.apache.org> - New Energy for Java --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
