I've deleted the branch-3.0-preview branch, and added `3.0.0-preview` tag to master (https://github.com/apache/spark/releases/tag/3.0.0-preview). I'll be working on make a RC now.
Cheers, Xingbo Sean Owen <sro...@gmail.com> 于2019年10月17日周四 下午4:23写道： > Sure, if that works, that's a simpler solution. The preview release is > like an RC of the master branch itself. > Are there any issues with that approach right now? > Yes if it turns out that we can't get a reasonably stable release off > master, then we can branch and cherry-pick. We'd have to retain the > branch though. > > On Thu, Oct 17, 2019 at 12:28 AM Xingbo Jiang <jiangxb1...@gmail.com> > wrote: > > > > How about add `3.0.0-preview` tag on master branch, and claim that for > the preview release, we won't consider bugs introduced by new features > merged into master after the first preview RC ? This could rule out the > risk that we keep on import new commits and need to resolve more critical > bugs thus the release would never converge. > > > > Cheers, > > > > Xingbo > > > > Sean Owen <sro...@gmail.com> 于2019年10月16日周三 下午6:34写道： > >> > >> 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. >
