(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
