One thing we can do is to do monthly milestone releases, similar to other projects (e.g. Scala).
So we can have Apache Spark 2.1.0-M1, Apache Spark 2.1.0-M2. On Thu, Jun 2, 2016 at 12:42 PM, Tom Graves <tgraves...@yahoo.com> wrote: > The documentation for the preview release also seem to be missing? > > Also what happens if we want to do a second preview release? The naming > doesn't seem to allow then unless we call it preview 2. > > Tom > > > On Wednesday, June 1, 2016 6:27 PM, Sean Owen <so...@cloudera.com> wrote: > > > 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 > > > > >
