incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: [VOTE] Drop incubating requirement of Maven artifacts
Date Sat, 07 Jan 2017 13:36:34 GMT
Niclas,

I wanted to read through your notes pretty in depth before responding.

On Thu, Jan 5, 2017 at 7:37 PM 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.
>
>
Thank you for acknowledging this.


> 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.
>

I think this is a fair point, and probably close to what podling
communities do (when its a fairly new codebase).  We often see releases in
the 0.x line, and in the 1+ lines.  Its up to the podling to determine how
mature they are from a release numbering standpoint.  I wouldn't want the
IPMC to enforce a versioning scheme.

It does however seem like a foundation wide versioning scheme may make
sense, or at least references to common references, e.g. semver, may make
sense as a recommendation to new podlings.


>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message