Personally I'd just put them on the staging repo and link to that on the downloads page. It will create less confusion for people browsing Maven Central later and wondering which releases are safe to use.
Matei > On Jun 3, 2016, at 8:22 AM, Mark Hamstra <m...@clearstorydata.com> wrote: > > It's not a question of whether the preview artifacts can be made available on > Maven central, but rather whether they must be or should be. I've got no > problems leaving these unstable, transitory artifacts out of the more > permanent, canonical repository. > > On Fri, Jun 3, 2016 at 1:53 AM, Steve Loughran <ste...@hortonworks.com > <mailto:ste...@hortonworks.com>> wrote: > > It's been voted on by the project, so can go up on central > > There's already some JIRAs being filed against it, this is a metric of > success as pre-beta of the artifacts. > > The risk of exercising the m2 central option is that people may get > expectations that they can point their code at the 2.0.0-preview and then, > when a release comes out, simply > update their dependency; this may/may not be the case. But is it harmful if > people do start building and testing against the preview? If it finds > problems early, it can only be a good thing > > > > On 1 Jun 2016, at 23:10, Sean Owen <so...@cloudera.com > > <mailto:so...@cloudera.com>> wrote: > > > > I'll be more specific about the issue that I think trumps all this, > > which I realize maybe not everyone was aware of. > > > > There was a long and contentious discussion on the PMC about, among > > other things, advertising a "Spark 2.0 preview" from Databricks, such > > as at > > https://databricks.com/blog/2016/05/11/apache-spark-2-0-technical-preview-easier-faster-and-smarter.html > > > > <https://databricks.com/blog/2016/05/11/apache-spark-2-0-technical-preview-easier-faster-and-smarter.html> > > > > That post has already been updated/fixed from an earlier version, but > > part of the resolution was to make a full "2.0.0 preview" release in > > order to continue to be able to advertise it as such. Without it, I > > believe the PMC's conclusion remains that this blog post / product > > announcement is not allowed by ASF policy. Hence, either the product > > announcements need to be taken down and a bunch of wording changed in > > the Databricks product, or, this needs to be a normal release. > > > > Obviously, it seems far easier to just finish the release per usual. I > > actually didn't realize this had not been offered for download at > > http://spark.apache.org/downloads.html > > <http://spark.apache.org/downloads.html> either. It needs to be > > accessible there too. > > > > > > We can get back in the weeds about what a "preview" release means, > > but, normal voted releases can and even should be alpha/beta > > (http://www.apache.org/dev/release.html > > <http://www.apache.org/dev/release.html>) The culture is, in theory, to > > release early and often. I don't buy an argument that it's too old, at > > 2 weeks, when the alternative is having nothing at all to test > > against. > > > > On Wed, Jun 1, 2016 at 5:02 PM, Michael Armbrust <mich...@databricks.com > > <mailto:mich...@databricks.com>> wrote: > >>> I'd think we want less effort, not more, to let people test it? for > >>> example, right now I can't easily try my product build against > >>> 2.0.0-preview. > >> > >> > >> I don't feel super strongly one way or the other, so if we need to publish > >> it permanently we can. > >> > >> However, either way you can still test against this release. You just need > >> to add a resolver as well (which is how I have always tested packages > >> against RCs). One concern with making it permeant is this preview release > >> is already fairly far behind branch-2.0, so many of the issues that people > >> might report have already been fixed and that might continue even after the > >> release is made. I'd rather be able to force upgrades eventually when we > >> vote on the final 2.0 release. > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org > > <mailto:dev-unsubscr...@spark.apache.org> > > For additional commands, e-mail: dev-h...@spark.apache.org > > <mailto:dev-h...@spark.apache.org> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org > <mailto:dev-unsubscr...@spark.apache.org> > For additional commands, e-mail: dev-h...@spark.apache.org > <mailto:dev-h...@spark.apache.org> > >
