Great! Thank you!
Bests,
Dongjoon.
On Thu, Oct 17, 2019 at 10:19 Xingbo Jiang 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
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 于2019年10月17日周四 下午4:23写道：
> Sure, if that works, that's a simpler solution. The preview
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
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
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
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
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
Can we just tag master?
On Wed, Oct 16, 2019 at 12:34 AM, Wenchen Fan < cloud0...@gmail.com > wrote:
>
> Does anybody remember what we did for 2.0 preview? Personally I'd like to
> avoid cutting branch-3.0 right now, otherwise we need to merge PRs into
> two branches in the following several
Does anybody remember what we did for 2.0 preview? Personally I'd like to
avoid cutting branch-3.0 right now, otherwise we need to merge PRs into two
branches in the following several months.
Thanks,
Wenchen
On Wed, Oct 16, 2019 at 3:01 PM Xingbo Jiang wrote:
> Hi Dongjoon,
>
> I'm not sure
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
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.
11 matches
Mail list logo
