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 14:42:18 GMT
On Sat, Jan 7, 2017 at 9:23 AM Niclas Hedhman <niclas@hedhman.org> wrote:

> On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament <johndament@apache.org>
> wrote:
>
> > > 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.
>
> Yeah, this is a tricky question. On one hand I don't like to dictate, but
> as a user I like to have a unified view of the world. Perhaps one or two
> DOAP entries would be a good way, and more strongly promote the DOAP and
> over time our common tooling could provide the unified view. A bit of "be a
> good citizen.... for your own sake" attitude.
>
>
I'm not sure what you mean by DOAP entries.  Do you have an example?

John



>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

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