As far as I know any JIRA that has implications for users is tagged this way but I haven't examined all of them. All that are going in for 3.0 should have it as Fix Version . Most changes won't have a user visible impact. Do you see any that seem to need the tag? Call em out or even fix them by adding the tag and proposed release notes.
On Tue, Nov 13, 2018, 11:49 AM Matt Cheah <mch...@palantir.com wrote: > The release-notes label on JIRA sounds good. Can we make it a point to > have that done retroactively now, and then moving forward? > > On 11/12/18, 4:01 PM, "Sean Owen" <sro...@apache.org> wrote: > > My non-definitive takes -- > > I would personally like to remove all deprecated methods for Spark 3. > I started by removing 'old' deprecated methods in that commit. Things > deprecated in 2.4 are maybe less clear, whether they should be removed > > Everything's fair game for removal or change in a major release. So > far some items in discussion seem to be Scala 2.11 support, Python 2 > support, R support before 3.4. I don't know about other APIs. > > Generally, take a look at JIRA for items targeted at version 3.0. Not > everything targeted for 3.0 is going in, but ones from committers are > more likely than others. Breaking changes ought to be tagged > 'release-notes' with a description of the change. The release itself > has a migration guide that's being updated as we go. > > > On Mon, Nov 12, 2018 at 5:49 PM Matt Cheah <mch...@palantir.com> > wrote: > > > > I wanted to clarify what categories of APIs are eligible to be > broken in Spark 3.0. Specifically: > > > > > > > > Are we removing all deprecated methods? If we’re only removing some > subset of deprecated methods, what is that subset? I see a bunch were > removed in > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_spark_pull_22921&d=DwIFaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=hzwIMNQ9E99EMYGuqHI0kXhVbvX3nU3OSDadUnJxjAs&m=yQSElmBeMSlm-LdOsYqwPm3ZZJaoBktOmNYSGTF7FKk&s=_pRqHGBRV-RX3Ij_qSDb7bevUDmqENa-4caKSr5xs88&e= > for example. Are we only committed to removing methods that were deprecated > in some Spark version and earlier? > > Aside from removing support for Scala 2.11, what other kinds of > (non-experimental and non-evolving) APIs are eligible to be broken? > > Is there going to be a way to track the current list of all proposed > breaking changes / JIRA tickets? Perhaps we can include it in the JIRA > ticket that can be filtered down to somehow? > > > > --------------------------------------------------------------------- > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > > >
