branch-3.0 vs branch-3.0-preview (?)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

branch-3.0 vs branch-3.0-preview (?)

Dongjoon Hyun-2
Hi, 

It seems that we have `branch-3.0-preview` branch.


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.
Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

Jiang Xingbo
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 <[hidden email]> 于2019年10月16日周三 上午6:26写道:
Hi, 

It seems that we have `branch-3.0-preview` branch.


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.
Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

cloud0fan
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 <[hidden email]> 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 <[hidden email]> 于2019年10月16日周三 上午6:26写道:
Hi, 

It seems that we have `branch-3.0-preview` branch.


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.
Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

rxin
Can we just tag master?


On Wed, Oct 16, 2019 at 12:34 AM, Wenchen Fan <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 于2019年10月16日周三 上午6:26写道:
Hi, 

It seems that we have `branch-3.0-preview` branch.


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.

Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

Sean Owen-2
In reply to this post by Jiang Xingbo
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 <[hidden email]> 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 <[hidden email]> 于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: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

Dongjoon Hyun-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 于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.
Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

Sean Owen-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 于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: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

Jiang Xingbo
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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 于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.
Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

Sean Owen-2
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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 于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: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

Jiang 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 于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.
Reply | Threaded
Open this post in threaded view
|

Re: branch-3.0 vs branch-3.0-preview (?)

Dongjoon Hyun-2
Great! Thank you!

Bests,
Dongjoon.

On Thu, Oct 17, 2019 at 10:19 Xingbo Jiang <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 于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.