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> 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 > > 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 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) 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> > 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 > For additional commands, e-mail: dev-h...@spark.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org