On Tue, Jan 3, 2017 at 7:53 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 2017-01-03 13:45 GMT+01:00 Cédric Champeau <cedric.champ...@gmail.com>: > > > 2017-01-03 13:41 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > > > > > 2017-01-03 13:38 GMT+01:00 Cédric Champeau <cedric.champ...@gmail.com > >: > > > > > > > +1 > > > > > > > > Note that for Groovy, the source artifact, which is what legal is all > > > > about, contained the -incubating appendix. The Maven artifacts did > not, > > > and > > > > I think it's a reasonable thing: people were used to stable versions > of > > > > Groovy for years, there was no reason why a new one wouldn't be. > > > > > > > > > > > @Cédric: incubator is not about code maturity so still think it makes > > sense > > > (but agree for very big projects - by users - like groovy which are > > widely > > > used already it is weird so can be the exception confirming the rule?) > > > > > > > > Yes but the problem is that "incubating" carries the concept of maturity. > > So I was ok to have it in the source zip file name, because that is the > > reference that the ASF cares about, legally speaking. But Maven > > coordinates, including the version string, should not be affected by this > > policy. In other words, the requirement should not leak into technical > > aspects of consuming an artifact. > > > > > Think most of maven users will never grab the source zip and don't even > care so it is important to still reflect this maturity issue in what they > use (+ it is consistent since we release a single version and not 2: one > for legal and one for user) > Same can be said for ruby gem users and pypi users. In fact, for ruby gems at least you don't even need a version. > > > > > > > > > > > 2017-01-03 13:25 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > > > > > > > 2017-01-03 13:06 GMT+01:00 Guillaume Laforge <glafo...@gmail.com>: > > > > > > > > > > > When you say "it denotes a lack of maturity which is exactly the > > > > purpose > > > > > > AFAIK", what do you mean my maturity? > > > > > > Maturity in terms of how well it follows Apache processes and > > > > principles? > > > > > > Or in terms of "the project is not ready for prime time"? > > > > > > > > > > > > For example, for Apache Groovy, the project was very mature, and > > was > > > > > > already 11 years old when it joined the ASF. > > > > > > It was very stable, very mature, very solid. > > > > > > And it was a bit weird to append "-incubating", as people thought > > it > > > > > meant > > > > > > "not ready for prime time" rather that "going through ASF > > > incubation". > > > > > > Furthermore it forced users to also change the appId although > they > > > > > usually > > > > > > change only the version number, which might be in some property > > file > > > > > > externally. It's not such a big big deal, but it's still > something > > > they > > > > > had > > > > > > to do, which is a bit unconvenient. > > > > > > > > > > > > > > > > > And that is exactly this. Don't get me wrong, I'm part of several > > > > > incubating projects and I don't like to have -incubating cause it > > looks > > > > not > > > > > mature where sometimes code is very robust...but the project is > > > immature > > > > - > > > > > otherwise it wouldn't be in incubator. Even for groovy, there were > > few > > > > > chances but still some, it doesn't match ASF and it could have > moved > > > > > somewhere else which is a stability issue which is important to > show > > in > > > > the > > > > > published artifacts. > > > > > > > > > > Not sure I get the appId since most incubator projects don't > reflect > > > the > > > > > state in the groupId but only the version for this exact reason > (make > > > > user > > > > > upgrade from incubator to TLP just a version to change and not all > > > > > coordinates - which makes the classifier as bad as the groupId and > > > > version > > > > > a good compromise). > > > > > > > > > > > > > > > > I also second the idea that such a rule should apply to all kind > of > > > > > > artifacts or none, but not be an exception of Maven artifacts. > > > > > > It doesn't make sense to enforce a rule for just one... and hence > > the > > > > > idea > > > > > > of lifting that rule altogether for everybody. > > > > > > > > > > > > On Tue, Jan 3, 2017 at 12:55 PM, Romain Manni-Bucau < > > > > > rmannibu...@gmail.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > -1, I think it is important to show that the artifact > dependency > > is > > > > not > > > > > > > stable and should be used as such (if the project never > > graduates, > > > > even > > > > > > if > > > > > > > code is very mature then you still get all the troubles you can > > > think > > > > > > > about). > > > > > > > > > > > > > > Question is IMHO the opposite: why others don't follow the > > > > -incubating > > > > > > rule > > > > > > > as well? > > > > > > > > > > > > > > PS: of course an alternative to follow maven common practise > > would > > > be > > > > > to > > > > > > > put incubating in the groupId instead of version but in > practise > > we > > > > > have > > > > > > > more easily a placeholder for the version than the groupId so I > > > still > > > > > > think > > > > > > > version is the easiest place for users. Also note no user > > > complained > > > > > > about > > > > > > > that excepted about the fact it denotes a lack of maturity > which > > is > > > > > > exactly > > > > > > > the purpose AFAIK. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Romain Manni-Bucau > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog > > > > > > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/ > > > > > > > rmannibucau> | > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE > > > Factory > > > > > > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > > > > > > > > > > > 2017-01-03 12:50 GMT+01:00 Myrle Krantz <mkra...@mifos.org>: > > > > > > > > > > > > > > > +1 non-binding > > > > > > > > > > > > > > > > If a best practice targets only maven and not the others, > > > wouldn't > > > > > that > > > > > > > be > > > > > > > > a reason for a podling to consider avoiding using maven to > > > > distribute > > > > > > > > binaries at all? Is it fair for Apache to disadvantage maven > > > that > > > > > way? > > > > > > > > > > > > > > > > Can Apache enforce policies about binaries not released under > > the > > > > > > Apache > > > > > > > > name? Wouldn't that sort of policy be in contradiction to the > > > > Apache > > > > > > > > license? > > > > > > > > > > > > > > > > Keeping a best practice which is not only unenforceable and > > > > > > inconsistent, > > > > > > > > but also disadvantageous to any project which tries to follow > > it, > > > > > > > > discredits other best practices as well. (Broken windows > > theory) > > > > > > > > > > > > > > > > Greets from Germany > > > > > > > > Myrle > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 3, 2017 at 12:34 PM, 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/ > > > > > c6daddf2d564685acdcd14a876bebf > > > > > > > > > 392b25c268905b353e36b3cac5@%3Cgeneral.incubator.apache.org > % > > 3E > > > > > > > > > [2]: > > > > > > > > > http://incubator.apache.org/guides/release-java.html#best- > > > > > > > practice-maven > > > > > > > > > [3]: > > > > > > > > > https://lists.apache.org/thread.html/ > > > > > 0b6c065a908c5f9ec39fa78c31b39c > > > > > > > > > 83a6fea29eb34fada0ee070413@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-unsubscribe@incubator. > > > > apache.org > > > > > > > > > > For additional commands, e-mail: > > > general-help@incubator.apache. > > > > > org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Guillaume Laforge > > > > > > Apache Groovy committer & PMC Vice-President > > > > > > Developer Advocate @ Google Cloud Platform > > > > > > > > > > > > Blog: http://glaforge.appspot.com/ > > > > > > Social: @glaforge <http://twitter.com/glaforge> / Google+ > > > > > > <https://plus.google.com/u/0/114130972232398734985/posts> > > > > > > > > > > > > > > > > > > > > >
