-1 (binding) I look at the “-incubating” tag in the same way I do the DISCLAIMER file and the podling website disclaimer — As an indicator and reminder that a release may not be completely clean from a licensing/policy perspective.
-Taylor > On Jan 3, 2017, at 4:20 PM, Josh Elser <els...@apache.org> wrote: > > (late to the party) > > -1 (binding) as an ask to table the VOTE and try to reach some better > consensus. > > I have to agree with Julian that some more discussion may be prudent here. > There are definitely two divided camps, both of which bring good points to > the table. > > * Differing policies for the languages/tools of products that podlings create > (maven projects vs. python/ruby projects). Julian states this very well. > > * A clear definition of what the IPMC thinks "x.y.z-incubating" should mean > and some better public-facing docs on what "incubating releases" actually > mean. > - Groovy is a great, recent example. They were a very "mature" software > project, but still were "immature" in the terms of an ASF community (purely > speaking of them as being a podling, not a TLP). Personally, if I see the > -incubating suffix on a version, I can recognize that the *community* is the > thing at risk. However, I can also see how those less affiliated with the > incubator could interpret it as "software quality". John states this very > well in the VOTE text itself -- it leaves me wondering if we couldn't just be > more clear out of the gates. > > I also need to re-read the original thread from freemarker (no [DISCUSS] in > the subject and the holidays kept me from reading it closely) to think about > the original stated problem some more. > > - Josh > > Julian Hyde wrote: >> John, >> >> I see your points, and hopefully you see mine. I think we can agree on one >> thing: we have not reached consensus. :) >> >> The inconsistency among build tools is a red herring. If we want consistency >> across build tools (and more importantly across package formats, regardless >> of the tool used to build them), let’s first figure out what we want, and >> apply this to all build tools. >> >> Julian >> >> >>> On Jan 3, 2017, at 3:34 AM, John D. Ament<johndam...@apache.org> wrote: >>> >>> Carsten, Julian, >>> >>> I want to reiterate my notes from a prior message [1] in case there is any >>> confusion over the ask. There is a "best practice" around maven specific >>> releases that has been treated as policy, [2]. This best practice for >>> some reason is only applied if you are using the maven build tool. E.g. >>> published python packages, ruby gems do not have this requirement. The >>> purpose of this thread is to realign maven specific releases with the other >>> convenience binaries published by podlings. >>> >>> This is not intended to drop the -incubator/-incubating tag applied to >>> source releases. It was however established in 2008 [3] that releases >>> published by the incubator were endorsed, the -incubator/incubating tag was >>> to imply that the project itself was not considered stable and could go >>> away. >>> >>> John >>> >>> [1]: >>> https://lists.apache.org/thread.html/c6daddf2d564685acdcd14a876bebf392b25c268905b353e36b3cac5@%3Cgeneral.incubator.apache.org%3E >>> [2]: >>> http://incubator.apache.org/guides/release-java.html#best-practice-maven >>> [3]: >>> https://lists.apache.org/thread.html/0b6c065a908c5f9ec39fa78c31b39c83a6fea29eb34fada0ee070413@1222432864@%3Cgeneral.incubator.apache.org%3E >>> >>> >>> On Tue, Jan 3, 2017 at 1:47 AM Carsten Ziegeler<cziege...@apache.org> >>> wrote: >>> >>>> -1 >>>> >>>> I followed the "other thread" but it's still unclear to me what real >>>> problem this tries to solve. >>>> As others noted, there should be an indicator whether this is already an >>>> official Apache project or in the incubator and adding it to the version >>>> information is the solution with causes the least amount of pain for >>>> users. It's a simple marker, clearly visible for any user. >>>> And once the project is out of the incubator, users simply need to >>>> update to a new version - something which they would do anyway. >>>> >>>> Carsten >>>> >>>> John D. Ament 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Carsten Ziegeler >>>> Adobe Research Switzerland >>>> cziege...@apache.org >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
