Great! Thank you! Bests, Dongjoon.
On Thu, Oct 17, 2019 at 10:19 Xingbo Jiang <jiangxb1...@gmail.com> wrote: > 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. >> >
