Nicolas, all, Despite your believes, you do release communities. Because the community is the incubating project. Only after the community meets the criteria of graduation a proposal is submitted, seconded by the IPMC and reviewed by the board. The community works the code during incubation until it consistently meets just one (small set) of the graduation criteria (compliance to ASF rules). But all the other aspects (community size, diversity and interaction) are far more important for the success, given the principle Community over Code.
Otherwise, your suggestion to use the same standards for releasing as tlp (released communities) and the examples brought forward look very sound and acceptable. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Fri, Jan 6, 2017 at 1: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 >
