I agree that it seems completely fine to update the web version of the docs after a release. What would not be fine is updating the downloadable package for it without another vote (and another release number). When people voted on a release, they voted that we should put up that package as "spark-2.1.0.tgz" or whatever, which is not changing here.
At the same time though, even though docs on the website *can* be updated after, it might not be smart to release something until the docs *are* fully in sync with the new features -- otherwise users might get confused. Matei > On Jun 8, 2017, at 3:25 PM, Ryan Blue <rb...@netflix.com.INVALID> wrote: > > I've never thought that docs are strictly part of a release and can't be > updated outside of one. Javadoc jars are included in releases with jars, but > that's more because they are produced by the build and are tied to the source > code. There is plenty of other documentation that isn't normally included in > a release, like the project's web pages and wiki content. I think the > expectation is for that to be continuously updated. So my interpretation is > that the release artifacts in the document you're quoting from are the source > code and convenience binaries. There's definitely room for interpretation > here, but I don't think it would be a problem as long as we do something > reasonable. > > On Tue, Jun 6, 2017 at 2:15 AM, Sean Owen <so...@cloudera.com > <mailto:so...@cloudera.com>> wrote: > That's good, but, I think we should agree on whether release docs are part of > a release. It's important to reasoning about releases. > > To be clear, you're suggesting that, say, right now you are OK with updating > this page with a few more paragraphs? > http://spark.apache.org/docs/2.1.0/streaming-programming-guide.html > <http://spark.apache.org/docs/2.1.0/streaming-programming-guide.html> Even > though those paragraphs can't be in the released 2.1.0 doc source? > > First, what is everyone's understanding of the answer? > > The only official guidance I can find is > http://www.apache.org/legal/release-policy.html#distribute-other-artifacts > <http://www.apache.org/legal/release-policy.html#distribute-other-artifacts> > , which suggests that docs need to be released similarly, with signatures. > Not quite the same question, but strongly implies they're treated like any > other source that is released with a vote. > > ------ > > WHAT ARE THE REQUIREMENTS TO DISTRIBUTE OTHER ARTIFACTS IN ADDITION TO THE > SOURCE PACKAGE? > <http://www.apache.org/legal/release-policy.html#distribute-other-artifacts> > ASF releases typically contain additional material together with the source > package. This material may include documentation concerning the release but > must contain LICENSE and NOTICE files. As mentioned above, these artifacts > must be signed by a committer with a detached signature if they are to be > placed in the project's distribution directory. > > Again, these artifacts may be distributed only if they contain LICENSE and > NOTICE files. For example, the Java artifact format is based on a compressed > directory structure and those projects wishing to distribute jars must place > LICENSE and NOTICE files in the META-INF directory within the jar. > > Nothing in this section is meant to supersede the requirements defined here > <http://www.apache.org/legal/release-policy.html#what> and here > <http://www.apache.org/legal/release-policy.html#what-must-every-release-contain> > that all releases be primarily based on a signed source package. > > > On Tue, Jun 6, 2017 at 9:50 AM Nick Pentreath <nick.pentre...@gmail.com > <mailto:nick.pentre...@gmail.com>> wrote: > The website updates for ML QA (SPARK-20507) are not actually critical as the > project website certainly can be updated separately from the source code > guide and is not part of the release to be voted on. In future that > particular work item for the QA process could be marked down in priority, and > is definitely not a release blocker. > > In any event I just resolved SPARK-20507, as I don't believe any website > updates are required for this release anyway. That fully resolves the ML QA > umbrella (SPARK-20499). > > > > > -- > Ryan Blue > Software Engineer > Netflix
