You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spark.apache.org by Dongjoon Hyun <do...@gmail.com> on 2019/10/16 04:17:20 UTC
branch-3.0 vs branch-3.0-preview (?)
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.
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Dongjoon Hyun <do...@gmail.com>.
Great! Thank you!
Bests,
Dongjoon.
On Thu, Oct 17, 2019 at 10:19 Xingbo Jiang <ji...@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 <sr...@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 <ji...@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 <sr...@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.hyun@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 <sr...@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 <ji...@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 <do...@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.
>>
>
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Xingbo Jiang <ji...@gmail.com>.
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 <sr...@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 <ji...@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 <sr...@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 <do...@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 <sr...@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 <ji...@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 <do...@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.
>
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Sean Owen <sr...@gmail.com>.
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 <ji...@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 <sr...@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 <do...@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 <sr...@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 <ji...@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 <do...@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-unsubscribe@spark.apache.org
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Xingbo Jiang <ji...@gmail.com>.
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 <sr...@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 <do...@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 <sr...@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 <ji...@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 <do...@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.
>
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Sean Owen <sr...@gmail.com>.
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 <do...@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 <sr...@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 <ji...@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 <do...@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-unsubscribe@spark.apache.org
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Dongjoon Hyun <do...@gmail.com>.
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 <sr...@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 <ji...@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 <do...@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.
>
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Sean Owen <sr...@gmail.com>.
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 <ji...@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 <do...@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-unsubscribe@spark.apache.org
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Reynold Xin <rx...@databricks.com>.
Can we just tag master?
On Wed, Oct 16, 2019 at 12:34 AM, Wenchen Fan < cloud0fan@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 months.
>
>
> Thanks,
> Wenchen
>
> On Wed, Oct 16, 2019 at 3:01 PM Xingbo Jiang < jiangxb1987@ gmail. com (
> jiangxb1987@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. hyun@ gmail. com ( dongjoon.hyun@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 (
>>> 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.
>>>
>>
>>
>
>
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Wenchen Fan <cl...@gmail.com>.
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 <ji...@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 <do...@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.
>>
>
Re: branch-3.0 vs branch-3.0-preview (?)
Posted by Xingbo Jiang <ji...@gmail.com>.
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 <do...@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.
>