Below, explains my own views on the version string (and other labels and points to mention "-incubating"), and is why I gave a +1 to John's vote. Less invasion.
Re: package names. Apache Subversion introduced new org.apache packages in its new release, and left it's old org.tigris packages available for backwards compat. Both are shims to expose our C libraries into Java, so that approach may have been easier for us, compared to Apache Groovy's situation. On Jan 4, 2017 02:25, "Cédric Champeau" <cedric.champ...@gmail.com> wrote: > 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 > > > > > > > > >
