I would argue that one of the Foundation mottos is "community first". In that sense, enforcing a policy like that is not thinking about users. It's adding a burden they don't care about. I am strongly against anything that enforces technical requirements where there shouldn't be. Enforcing Maven coordinates, or enforcing a _version string_ is going too far into the technical details. There's branding and there's technical. Maven already makes the mistake of mixing how you build the project and how you consume it, which is the root of a lot of pain. Let's not make the error again at the policy level, it's a total non sense.
The Foundation can host a variety of different projects, from new ones written in C to "old" ones written in Java, and all the different things we can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_ you consume a project, by Maven coordinates or version string is an implementation detail. Branding the project is not. In other words, as long as your package name, maven artifacts, Docker images, ... do not infringe copyright, it's a no brainer. However, the project page *must* state about incubating status and *explain* what it means. A *lot* of people don't care what *incubating* means in the Foundation sense (and even worse, podling can have very negative image). It would have been terrible for Groovy to change the way people consume the artifacts, making them think of low quality software, because they don't understand what "incubating" mean. To me it sounds even worse than "alpha". Since "incubating" is meant towards *incubating project in the sense of the Apache community*, it should *only* appear where it makes sense: DISCLAIMER, web site, ... That is to say everywhere you can give an explanation about its meaning. It should also appear in the source package name, because that is what we legally care about. But the version *string*, inside the package, is purely, again, internal details, just like package name, Maven coordinates, NPM coordinates, ... Why would you force me to use a version pattern if what I want is the revision hash as the version number? The policy should NOT impact how we design software or how we want the design to be. There are potential technical issues with putting such a label in a version string (OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to name the Java ecosystem), so to me enforcing the policy here is just an error. As for Groovy and the Codehaus package and Maven coordinates, we plan to change this in a major, breaking, 3.0 release, not before. Because it would be a breaking change, and some dependency management engines, typically, are very poor when it comes to dependency substitution, which would add too much burden for people to upgrade. We had an agreement with Ben from Codehaus to use the name when we joined the ASF. 2017-01-04 8:51 GMT+01:00 Pierre Smits <pierre.sm...@gmail.com>: > John, > > I guess the discussion will go on, every time the topic will be brought > forward to the public mailings lists. Conducting politics is part of the > human nature. Keeping the discussion going will have the Incubator project > running in circles. Calling a vote on a procedural change and reporting the > result will help the project. > > Not everything needs unanimous consent. A simple majority suffices to > establish a direction until the next vote on the same subject. > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Wed, Jan 4, 2017 at 7:28 AM, Mark Struberg <strub...@yahoo.de.invalid> > wrote: > > > I guess you are talking about log4j/log4j or the various commons-* > > groupIds? > > This is true, but for completness sake I want to point out that there is > a > > difference to use a different _unused_ groupId vs using a _foreign_ one. > > > > I guess everyone would agree that the ASF does not like to publish > > artifacts with a com.oracle groupId, right? > > > > I'm a bit surprised that groovy still uses the org.codehaus groupId, but > I > > guess they have a deal with Ben (the former owner and thus (former?) > > copyright holder of 'Codehaus'). > > So while this will work for now I guess that even groovy will move to > > org.apache.groovy in the long term (maybe with a new major version). > > > > It's not a big deal YET, but http://codehaus.org is not reachable > > anymore. And if anyone buys this domain he will have a much better > position > > regarding trademarks than we do. > > What if someone buys the codehaus.org domain and publishes own artifacts > > under org.codehaus.groovy? Can we even prevent someone else to e.g > publish > > org.codehaus.groovyng artifacts? > > > > LieGrue, > > strub > > > > > Am 04.01.2017 um 02:49 schrieb John D. Ament <johndam...@apache.org>: > > > > > > On Tue, Jan 3, 2017 at 8:43 PM Daniel Dekany <ddek...@freemail.hu> > > wrote: > > > > > >> Tuesday, January 3, 2017, 11:10:24 PM, Stian Soiland-Reyes wrote: > > >> > > >> [snip] > > >>> The workaround of publishing binaries without any > > -incubator/-incubating > > >>> markers by using a non-apache group/name is probably a somewhat > > workable > > >>> solution for larger established projects like Groovy, but may also > work > > >>> against community as it de-emphasises ASF, and outsiders might so > > easily > > >>> realise that the community is changing before graduation. > > >> [snip] > > >> > > >> Note that the non-Apache group/name is not meant to be a workaround to > > >> avoid "-incubating". It's about not burdening the Java ecosystem with > > >> a groupId change. > > >> > > > > > > Just to point out, again, there are even top level projects that don't > > > publish under org.apache. There's no requirement to do so. > > > > > > > > >> > > >> -- > > >> Thanks, > > >> Daniel Dekany-incubating > > >> > > >> > > >> --------------------------------------------------------------------- > > >> 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 > > > > >
