On Wed, Jun 1, 2016 at 5:58 PM, Reynold Xin <r...@databricks.com> wrote: > The preview release is available here: > http://spark.apache.org/downloads.html (there is an entire section dedicated > to it and also there is a news link to it on the right).
Oops, it is indeed down there at the bottom, before nightlies. I honestly missed it below the fold. I'd advocate for making it a (non default?) option in the main downloads dropdown, but this then becomes a minor issue. The core source/binary artifacts _are_ publicly available. > "In addition to the distribution directory, project that use Maven or a > related build tool sometimes place their releases on repository.apache.org > beside some convenience binaries. The distribution directory is required, > while the repository system is an optional convenience." Agree. The question is what makes this release special? because other releases have been published to Maven. I think the argument is that it's a buggy alpha/beta/preview release, but so were 0.x releases. Reasonable people could make up different policies, so here I'm appealing to guidance: http://www.apache.org/dev/release.html "Releases are packages that have been approved for general public release, with varying degrees of caveat regarding their perceived quality or potential for change. Releases that are intended for everyday usage by non-developers are usually referred to as "stable" or "general availability (GA)" releases. Releases that are believed to be usable by testers and developers outside the project, but perhaps not yet stable in terms of features or functionality, are usually referred to as "beta" or "unstable". Releases that only represent a project milestone and are intended only for bleeding-edge developers working outside the project are called "alpha"." I don't think releases are defined by whether they're stable or buggy, but by whether they were produced by a sanctioned process that protects contributors under the ASF umbrella, etc etc. Compare to a nightly build which we don't want everyone to consume, not so much because it might be buggier, but because these protections don't apply. Certainly, it's vital to communicate how to interpret the stability of the releases, but -preview releases are still normal releases to the public. I don't think bugginess therefore is the question. Any Spark dev knows that x.y.0 Spark releases have gone out with even Critical and in the past Blocker issues unresolved, and the world failed to fall apart. (We're better about this now.) I actually think the -preview release idea is worth repeating for this reason -- .0-preview is the new .0. It'd be more accurate IMHO and better for all. > I think it'd be pretty bad if preview releases in anyway become "default > version", because they are unstable and contain a lot of blocker bugs. Why would this happen? releases happen ~3 months and could happen faster if this is a concern. 2.0.0 final is, I'd wager, coming in <1 month. > 2. On the download page, have two sections. One listing the normal releases, > and the other listing preview releases. +1, that puts it above the fold and easily findable to anyone willing to consume such a thing. > 3. Everywhere we mention preview releases, include the proper disclaimer > e.g. "This preview is not a stable release in terms of either API or > functionality, but it is meant to give the community early access to try the > code that will become Spark 2.0." Can't hurt to overcommunicate this for -preview releases in general. > 4. Publish normal releases to maven central, and preview releases only to > the staging maven repo. But of course we should include the temporary maven > repo for preview releases on the download page. This is the only thing I disagree with. AFAIK other ASF projects readily publish alpha and beta releases, under varying naming conventions (alpha, beta, RC1, etc) It's not something that needs to be hidden like a nightly. The audience for Maven artifacts are developers, not admins or users. Compare the risk of a developer somehow not understanding what they're getting, to the friction caused by making developers add a repo to get at it. I get it, that seems minor. But given the recent concern about making sure "2.0.0 preview" is available as an ASF release, I'd advise us to make sure this release is not any harder to get at than others, to really put that to bed. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
