We do not have to do anything to branch-3.0-preview; it's just for the convenience of the RM. Just continue to merge to master for 3.0.
If it happens that some state of the master branch works as a preview release, sure, just tag and release. We might get away with it. But if for example we have a small issue to fix with the preview and meanwhile something else has landed in the master branch that doesn't work, we'll struggle to get an RC out. I agree, that would be nice to not deal with this as a branch yet. But if we do: Yeah I figured the merge script would pick it up, which is a little annoying, but you can still just type branch-2.4. I think we have to retain the branch though if there are any cherry-picks, to record the state of the release. We don't want a "3.0-preview" version in JIRA. Let's fix the script if we must. So, I take it that the current preview RC didn't work. What if we delete that branch and try again from master? does that work? On Wed, Oct 16, 2019 at 11:19 AM Dongjoon Hyun <dongjoon.h...@gmail.com> wrote: > > Technically, `branch-3.0-preview` has many issues. > > First of all, are we going to delete `branch-3.0-preview` after releasing > `3.0-preview`? > I guess we didn't delete old branches (including feature branches like jdbc, > yarn branches) > > Second, our merge script already starts to show `branch-3.0-preview` instead > of `branch-2.4` already. > Currently, We need to merge to `master` -> `branch-3.0-preview` -> > `branch-2.4`. > This already creates a burden to maintain our LTS branch `branch-2.4`. > > Third, during updating JIRA, our merge script starts to fail because it > extracts the version number from `branch-3.0-preview` but Apache JIRA doesn't > have a version `3.0-preview`. Are we going to add a release version at > `Apache Spark JIRA`? > (I'm -1 for this. `Fixed Version: 3.0-preview` seems to be overkill). > > If we are reluctant to have `branch-3.0` because it has a meaning of > `feature` and its merging cost, I'm +1 for tag on `master` (Reynold's > suggestion) > > We can do vote and stabilize `3.0-alpha` in master branch. > > Bests, > Dongjoon. > > > On Wed, Oct 16, 2019 at 3:04 AM Sean Owen <sro...@gmail.com> wrote: >> >> I don't think we would want to cut 'branch-3.0' right now, which would >> imply that master is 3.1. We don't want to merge every new change into >> two branches. >> It may still be useful to have `branch-3.0-preview` as a short-lived >> branch just used to manage the preview release, as we will need to let >> development on 3.0 in master continue while stabilizing the preview >> release with a few selected cherry-picks, but that's only of concern >> to the release manager. >> >> On Wed, Oct 16, 2019 at 2:01 AM Xingbo Jiang <jiangxb1...@gmail.com> wrote: >> > >> > Hi Dongjoon, >> > >> > I'm not sure about the best practice of maintaining a preview release >> > branch, since new features might still go into Spark 3.0 after preview >> > release, I guess it might make more sense to have separated branches for >> > 3.0.0 and 3.0-preview. >> > >> > However, I'm open to both solutions, if we really want to reuse the branch >> > to also release Spark 3.0.0, then I would be happy to create a new one. >> > >> > Thanks! >> > >> > Xingbo >> > >> > Dongjoon Hyun <dongjoon.h...@gmail.com> 于2019年10月16日周三 上午6:26写道： >> >> >> >> Hi, >> >> >> >> It seems that we have `branch-3.0-preview` branch. >> >> >> >> https://github.com/apache/spark/commits/branch-3.0-preview >> >> >> >> Can we have `branch-3.0` instead of `branch-3.0-preview`? >> >> >> >> We can tag `v3.0.0-preview` on `branch-3.0` and continue to use for >> >> `v3.0.0` later. >> >> >> >> Bests, >> >> Dongjoon. --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
