I think the proposal doesn't mean to don't add the JIRAs with release-notes into the release notes (?). People will still label the JIRAs when the change is significant or breaking whether it's a bug or not, and they will be in the release notes. I guess the proposal TL;DR is: - If that's a legitimate breaking improvement, it goes to migration guides. - If the change is significant or breaking whether it's a bug or not, we label JIRA with release-notes, and add it into the release note.
But yeah since we're here, I guess it's better to articulate and document them. 2020년 6월 11일 (목) 오전 12:39, Sean Owen <sro...@gmail.com>님이 작성: > This seems like a change to current practice, as breaking changes are > marked for release notes with release-notes, etc: > https://spark.apache.org/contributing.html > My only concrete concern, is this seems to imply (?) that many JIRAs with > release-notes and Docs text are not going to get included in release notes. > They aren't anywhere then (3.0 is done, so not the migration guide). Some > are important. > Change could be OK but how about proposing this going forward? > > > On Wed, Jun 10, 2020 at 10:35 AM Wenchen Fan <cloud0...@gmail.com> wrote: > >> My 2 cents: >> >> Since we have a migration guide, I think people who hit problems when >> upgrading Spark will read it. We should mention all the breaking changes >> there, except for trivial ones like obvious bug fixes. Even if there is no >> meaningful migration to guide for things like removing a deprecated API, >> it's still useful to have an item in the migration guide, to explain why we >> remove it. >> >> Release notes, on the other hand, should include all the major things, >> like new features, improvements, new APIs, bug fixes, breaking changes, >> etc., as long as they are major. For example, dropping Scala 2.11 is a >> major breaking change and should be put in the release notes. That said, we >> may have some items in both the migration guide and the release notes. >> >> Release notes can be read by many people and I think it's better to not >> make it too verbose. >> >> >> >> On Tue, Jun 9, 2020 at 10:33 PM Sean Owen <sro...@gmail.com> wrote: >> >>> A few different takes surfaced: >>> >>> >>> https://issues.apache.org/jira/browse/SPARK-26043?focusedCommentId=17128908&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17128908 >>> >>> No significant disagreements, just might be worth clarifying a consensus >>> policy. >>> >>> "I feel this is a tiny thing that we should put into the migration >>> guide, not release notes? ... it depends on the definition of migration >>> guide and release notes: If I upgrade to 3.0 and hit compiler error, which >>> one should I read?" >>> >>> "I think it's the other way around: some things are worth noting, but >>> there is no meaningful migration to guide. So they go in release notes, not >>> a migration guide, if anything. Do we have a different understanding?" >>> >>> "Migration guide: legitimate improvements yet that are breaking. If >>> that's too trivial or minor, I wouldn't document. It depends on a >>> committer's call. >>> Release note: significant breaking changes including the bug fixes >>> and/or improvement. One JIRA could appear in both migration guide and >>> release notes if it's worthwhile." >>> >>
