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
