cloud-fan commented on PR #55878: URL: https://github.com/apache/spark/pull/55878#issuecomment-4453318597
@dongjoon-hyun Your suggestion makes me think what should be the rule of deciding the released versions. In the past, when we merge a PR to master only, the released version is the next feature release version (e.g. `4.1.0`), which implies that all releases after `4.1.0` will contains the commit. If the PR is also backported to a release branch, like `branch-4.0`, we additionally include the next maintenance release version (e.g. `4.0.2`), which indicates that releases before `4.0.2` do not have the commit. So the principle is to use a minimal set of released versions to tell users which Spark versions contain the commit. That being said: | Merge branches | released versions | |---|---| | `master` | `[5.0.0]` | | `master`, `branch-4.x` | `[4.3.0]` | | `master`, `branch-4.x`, `branch-4.2` | `[4.2.0]` | | `master`, `branch-4.x`, `branch-4.2` if 4.2.0 has released | `[4.3.0, 4.2.1]` | | `master`, `branch-4.2` | `[5.0.0, 4.2.0]` | | `master`, `branch-4.2` if 4.2.0 has released | `[5.0.0, 4.2.1]` | The last 2 rows are mostly for completeness, but it should not happen in practise. How do you think of this principle? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
