incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emilian Bold <...@apache.org>
Subject Re: [VOTE] Drop incubating requirement of Maven artifacts
Date Fri, 06 Jan 2017 07:30:19 GMT
>  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 <niclas@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 <johndament@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.dashorst@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 <johndament@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-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message