You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dolphinscheduler.apache.org by Xiaochun Liu <li...@apache.org> on 2020/05/13 05:43:38 UTC
[SUGGESTION]Release branch management
Hi, all
We encountered the following problems in the release branch management:
1. The release participation rate is low, it is difficult for community developers, or it is not easy to participate in the release process. It is mainly because everyone still fixes the bug by default, and the new features are placed in the dev branch. Finally, the release has become a matter of several people.
2. The waste of resources, the same bug, is amended in the release branch and development branch, wasting the energy and resources of the community.
3. The late merge workload is large, and the release cycle may last a long time. Then there will be a lot of conflicts in this period of time, and it will be difficult to choose when merging in the future.
recommended solution:
1. Establish the timing of the release branch. If you want to enter the release process, don't integrate the new feature into the dev branch for the time being. Only modify the bug for the time being. Try to complete the big changes in the dev branch, not on the new release branch. Make big adjustments to minimize conflicts with dev.
2. After establishing a new release branch, all bug fixes should be guided to the new release branch as much as possible. It is recommended to add tags to the issue of the release branch to mark it. When it is merged, priority is also added to this part of pr to increase the community. Participation in publishing.
3. After creating a new release branch, allow the integration of large changes and new features, and if it is a bug fix on dev, try to lead to the release branch.
4. The changes of the release branch should be merged to the dev branch as soon as possible to avoid the difficulty of joining together later, because your own changes can easily determine which one should be merged if there is a conflict.
——————————————
现在发版分支管理面临问题如下:
1、发版参与率低，社区开发者很难，或者不太容易参与发版流程，主要是大家还是默认的把bug修复，新功能放到了dev分支，最终发版成了几个人的事情。
2、资源的浪费，同样一个bug，在发版分支和开发分支都做修改，浪费社区的精力和资源。
3、后期merge工作量大，发版周期可能持续很长，那这个时间段内冲突会很多，将来做合并的时候会很难取舍。
建议解决方案:
1、建立发版分支的时机，如果想进入发版流程，dev分支暂时不要合入新的feature，暂时只修改bug，尽量把大的改动都在dev分支完成，不要在新的发版分支上面做大的调整，尽可能减少和dev冲突部分。
2、建立新的发版分支后，所有bug fix都尽量引导到新的发版分支上，建议对发版分支的issue增加tag来标记，合入的时候也优先合入这部分pr，增加社区的发版参与度。
3、建立新的发版分支后，允许较大改动新功能的合入，并且如果是在dev上的bug fix尽量往发版分支上引导。
4、发版分支的改动，应该尽快merge到dev分支，避免后期一起合入的困难，因为自己的改动如果冲突很容易判断应该合入哪个，到最后的话会很难。
Best Regards
---------------
DolphinScheduler(Incubator) Committer
Xiaochun Liu 刘小春
liuxiaochun@apache.org
---------------
Re: [SUGGESTION]Release branch management
Posted by Hemin Wen <we...@apache.org>.
I suggest, the bug fixes of the release version are preferentially merged
into the release branch.
Then the reviewer of PR are merged into the dev branch.
******************************
Apache DolphinScheduler
Hemin Wen (温合民)
wenhemin@apache.org
Xiaochun Liu <li...@apache.org> 于2020年5月18日周一 下午10:46写道：
>
> If everyone merge the changes on the release branch into the dev branch
> immediately,
> and it will not cost too much extra time. Because each change is limited,
> or there are very few conflicts.
>
> Best Regards
> ---------------
> DolphinScheduler(Incubator) Committer
> Xiaochun Liu 刘小春
> liuxiaochun@apache.org
> ---------------
>
>
>
> > 2020年5月18日 下午10:40，lidong dai <da...@gmail.com> 写道：
> >
> > any other's ideas?
> >
> >
> >
> > Best Regards
> > ---------------
> > DolphinScheduler(Incubator) PPMC
> > Lidong Dai 代立冬
> > dailidong66@gmail.com
> > ---------------
> >
> >
> > leon bao <le...@apache.org> 于2020年5月15日周五 上午10:32写道：
> >
> >> i agree to merge the changes to 'dev' timely.
> >> but how do we do it？
> >> whether the person who merges the code to merge the changes into the
> main
> >> branch.
> >>
>
>
Re: [SUGGESTION]Release branch management
Posted by Xiaochun Liu <li...@apache.org>.
If everyone merge the changes on the release branch into the dev branch immediately,
and it will not cost too much extra time. Because each change is limited, or there are very few conflicts.
Best Regards
---------------
DolphinScheduler(Incubator) Committer
Xiaochun Liu 刘小春
liuxiaochun@apache.org
---------------
> 2020年5月18日 下午10:40，lidong dai <da...@gmail.com> 写道：
>
> any other's ideas?
>
>
>
> Best Regards
> ---------------
> DolphinScheduler(Incubator) PPMC
> Lidong Dai 代立冬
> dailidong66@gmail.com
> ---------------
>
>
> leon bao <le...@apache.org> 于2020年5月15日周五 上午10:32写道：
>
>> i agree to merge the changes to 'dev' timely.
>> but how do we do it？
>> whether the person who merges the code to merge the changes into the main
>> branch.
>>
Re: [SUGGESTION]Release branch management
Posted by lidong dai <da...@gmail.com>.
any other's ideas?
Best Regards
---------------
DolphinScheduler(Incubator) PPMC
Lidong Dai 代立冬
dailidong66@gmail.com
---------------
leon bao <le...@apache.org> 于2020年5月15日周五 上午10:32写道：
> i agree to merge the changes to 'dev' timely.
> but how do we do it？
> whether the person who merges the code to merge the changes into the main
> branch.
>
Re: [SUGGESTION]Release branch management
Posted by leon bao <le...@apache.org>.
i agree to merge the changes to 'dev' timely.
but how do we do it？
whether the person who merges the code to merge the changes into the main
branch.
Re: [SUGGESTION]Release branch management
Posted by lidong dai <da...@gmail.com>.
I think what you said is more fit with the actual situation.
BTW，I think we can disscuss to find a better way to solve this problem if
we can
Best Regards
---------------
DolphinScheduler(Incubator) PPMC
Lidong Dai 代立冬
dailidong66@gmail.com
---------------
kezhenxu94@apache <ke...@apache.org> 于2020年5月13日周三 下午2:06写道：
>
> I’m totally confused why do you create a release branch if you’re going to
> continuously merge new codes into THIS release branch? IMO, “release
> branch” is for releasing and it aims to freeze the codes in some degree,
> new codes can be still merged into the “dev” branch, which doesn’t block
> the community. New codes can be merged into the “release branch” only when
> they’re critical in the Apache release process, license issues or branding
> problems, for example.
>
>
> GitHub @kezhenxu94, Opinions are my own
> Apache SkyWalking, Apache Dubbo
>
>
> > On May 13, 2020, at 13:43, Xiaochun Liu <li...@apache.org> wrote:
> >
> >
> > Hi, all
> >
> > We encountered the following problems in the release branch management:
> > 1. The release participation rate is low, it is difficult for community
> developers, or it is not easy to participate in the release process. It is
> mainly because everyone still fixes the bug by default, and the new
> features are placed in the dev branch. Finally, the release has become a
> matter of several people.
> > 2. The waste of resources, the same bug, is amended in the release
> branch and development branch, wasting the energy and resources of the
> community.
> > 3. The late merge workload is large, and the release cycle may last a
> long time. Then there will be a lot of conflicts in this period of time,
> and it will be difficult to choose when merging in the future.
> > recommended solution:
> > 1. Establish the timing of the release branch. If you want to enter the
> release process, don't integrate the new feature into the dev branch for
> the time being. Only modify the bug for the time being. Try to complete the
> big changes in the dev branch, not on the new release branch. Make big
> adjustments to minimize conflicts with dev.
> > 2. After establishing a new release branch, all bug fixes should be
> guided to the new release branch as much as possible. It is recommended to
> add tags to the issue of the release branch to mark it. When it is merged,
> priority is also added to this part of pr to increase the community.
> Participation in publishing.
> > 3. After creating a new release branch, allow the integration of large
> changes and new features, and if it is a bug fix on dev, try to lead to the
> release branch.
> > 4. The changes of the release branch should be merged to the dev branch
> as soon as possible to avoid the difficulty of joining together later,
> because your own changes can easily determine which one should be merged if
> there is a conflict.
> >
> > ——————————————
> > 现在发版分支管理面临问题如下:
> > 1、发版参与率低，社区开发者很难，或者不太容易参与发版流程，主要是大家还是默认的把bug修复，新功能放到了dev分支，最终发版成了几个人的事情。
> > 2、资源的浪费，同样一个bug，在发版分支和开发分支都做修改，浪费社区的精力和资源。
> > 3、后期merge工作量大，发版周期可能持续很长，那这个时间段内冲突会很多，将来做合并的时候会很难取舍。
> >
> > 建议解决方案:
> >
> 1、建立发版分支的时机，如果想进入发版流程，dev分支暂时不要合入新的feature，暂时只修改bug，尽量把大的改动都在dev分支完成，不要在新的发版分支上面做大的调整，尽可能减少和dev冲突部分。
> > 2、建立新的发版分支后，所有bug
> fix都尽量引导到新的发版分支上，建议对发版分支的issue增加tag来标记，合入的时候也优先合入这部分pr，增加社区的发版参与度。
> > 3、建立新的发版分支后，允许较大改动新功能的合入，并且如果是在dev上的bug fix尽量往发版分支上引导。
> > 4、发版分支的改动，应该尽快merge到dev分支，避免后期一起合入的困难，因为自己的改动如果冲突很容易判断应该合入哪个，到最后的话会很难。
> >
> >
> > Best Regards
> > ---------------
> > DolphinScheduler(Incubator) Committer
> > Xiaochun Liu 刘小春
> > liuxiaochun@apache.org
> > ---------------
> >
> >
> >
>
>
>
>
>
Re: [SUGGESTION]Release branch management
Posted by lidong dai <da...@gmail.com>.
I know what you said, i think you are right. but I'm a little confused, I
think we don't have enough energy for maintaining these two branches at the
same time, when pulling new publish branch, it means we will publish the
new version in the later time, and usually the left time is not enough.
how do you think?
Best Regards
---------------
DolphinScheduler(Incubator) PPMC
Lidong Dai 代立冬
dailidong66@gmail.com
---------------
JUN GAO <ga...@gmail.com> 于2020年5月13日周三 下午3:33写道：
> I agree with you !
>
> Xiaochun Liu <li...@apache.org> 于2020年5月13日周三 下午2:57写道：
>
> > @
> > > kezhenxu94
> >
> > I mean the new bug fix PR can be merged into the release branch, more
> > people can participate in release branch.
> >
> > Best Regards
> > ---------------
> > DolphinScheduler(Incubator) Committer
> > Xiaochun Liu 刘小春
> > liuxiaochun@apache.org
> > ---------------
> >
> >
> >
> > > 2020年5月13日 下午2:06，kezhenxu94@apache <ke...@apache.org> 写道：
> > >
> > >
> > > I’m totally confused why do you create a release branch if you’re going
> > to continuously merge new codes into THIS release branch? IMO, “release
> > branch” is for releasing and it aims to freeze the codes in some degree,
> > new codes can be still merged into the “dev” branch, which doesn’t block
> > the community. New codes can be merged into the “release branch” only
> when
> > they’re critical in the Apache release process, license issues or
> branding
> > problems, for example.
> > >
> > >
> > > GitHub @kezhenxu94, Opinions are my own
> > > Apache SkyWalking, Apache Dubbo
> > >
> > >
> > >> On May 13, 2020, at 13:43, Xiaochun Liu <li...@apache.org>
> wrote:
> > >>
> > >>
> > >> Hi, all
> > >>
> > >> We encountered the following problems in the release branch
> management:
> > >> 1. The release participation rate is low, it is difficult for
> community
> > developers, or it is not easy to participate in the release process. It
> is
> > mainly because everyone still fixes the bug by default, and the new
> > features are placed in the dev branch. Finally, the release has become a
> > matter of several people.
> > >> 2. The waste of resources, the same bug, is amended in the release
> > branch and development branch, wasting the energy and resources of the
> > community.
> > >> 3. The late merge workload is large, and the release cycle may last a
> > long time. Then there will be a lot of conflicts in this period of time,
> > and it will be difficult to choose when merging in the future.
> > >> recommended solution:
> > >> 1. Establish the timing of the release branch. If you want to enter
> the
> > release process, don't integrate the new feature into the dev branch for
> > the time being. Only modify the bug for the time being. Try to complete
> the
> > big changes in the dev branch, not on the new release branch. Make big
> > adjustments to minimize conflicts with dev.
> > >> 2. After establishing a new release branch, all bug fixes should be
> > guided to the new release branch as much as possible. It is recommended
> to
> > add tags to the issue of the release branch to mark it. When it is
> merged,
> > priority is also added to this part of pr to increase the community.
> > Participation in publishing.
> > >> 3. After creating a new release branch, allow the integration of large
> > changes and new features, and if it is a bug fix on dev, try to lead to
> the
> > release branch.
> > >> 4. The changes of the release branch should be merged to the dev
> branch
> > as soon as possible to avoid the difficulty of joining together later,
> > because your own changes can easily determine which one should be merged
> if
> > there is a conflict.
> > >>
> > >> ——————————————
> > >> 现在发版分支管理面临问题如下:
> > >>
> 1、发版参与率低，社区开发者很难，或者不太容易参与发版流程，主要是大家还是默认的把bug修复，新功能放到了dev分支，最终发版成了几个人的事情。
> > >> 2、资源的浪费，同样一个bug，在发版分支和开发分支都做修改，浪费社区的精力和资源。
> > >> 3、后期merge工作量大，发版周期可能持续很长，那这个时间段内冲突会很多，将来做合并的时候会很难取舍。
> > >>
> > >> 建议解决方案:
> > >>
> >
> 1、建立发版分支的时机，如果想进入发版流程，dev分支暂时不要合入新的feature，暂时只修改bug，尽量把大的改动都在dev分支完成，不要在新的发版分支上面做大的调整，尽可能减少和dev冲突部分。
> > >> 2、建立新的发版分支后，所有bug
> > fix都尽量引导到新的发版分支上，建议对发版分支的issue增加tag来标记，合入的时候也优先合入这部分pr，增加社区的发版参与度。
> > >> 3、建立新的发版分支后，允许较大改动新功能的合入，并且如果是在dev上的bug fix尽量往发版分支上引导。
> > >> 4、发版分支的改动，应该尽快merge到dev分支，避免后期一起合入的困难，因为自己的改动如果冲突很容易判断应该合入哪个，到最后的话会很难。
> > >>
> > >>
> > >> Best Regards
> > >> ---------------
> > >> DolphinScheduler(Incubator) Committer
> > >> Xiaochun Liu 刘小春
> > >> liuxiaochun@apache.org
> > >> ---------------
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
>
> --
>
> DolphinScheduler(Incubator) PPMC
> Jun Gao 高俊
> gaojun2048@gmail.com
>
Re: [SUGGESTION]Release branch management
Posted by JUN GAO <ga...@gmail.com>.
I agree with you !
Xiaochun Liu <li...@apache.org> 于2020年5月13日周三 下午2:57写道：
> @
> > kezhenxu94
>
> I mean the new bug fix PR can be merged into the release branch, more
> people can participate in release branch.
>
> Best Regards
> ---------------
> DolphinScheduler(Incubator) Committer
> Xiaochun Liu 刘小春
> liuxiaochun@apache.org
> ---------------
>
>
>
> > 2020年5月13日 下午2:06，kezhenxu94@apache <ke...@apache.org> 写道：
> >
> >
> > I’m totally confused why do you create a release branch if you’re going
> to continuously merge new codes into THIS release branch? IMO, “release
> branch” is for releasing and it aims to freeze the codes in some degree,
> new codes can be still merged into the “dev” branch, which doesn’t block
> the community. New codes can be merged into the “release branch” only when
> they’re critical in the Apache release process, license issues or branding
> problems, for example.
> >
> >
> > GitHub @kezhenxu94, Opinions are my own
> > Apache SkyWalking, Apache Dubbo
> >
> >
> >> On May 13, 2020, at 13:43, Xiaochun Liu <li...@apache.org> wrote:
> >>
> >>
> >> Hi, all
> >>
> >> We encountered the following problems in the release branch management:
> >> 1. The release participation rate is low, it is difficult for community
> developers, or it is not easy to participate in the release process. It is
> mainly because everyone still fixes the bug by default, and the new
> features are placed in the dev branch. Finally, the release has become a
> matter of several people.
> >> 2. The waste of resources, the same bug, is amended in the release
> branch and development branch, wasting the energy and resources of the
> community.
> >> 3. The late merge workload is large, and the release cycle may last a
> long time. Then there will be a lot of conflicts in this period of time,
> and it will be difficult to choose when merging in the future.
> >> recommended solution:
> >> 1. Establish the timing of the release branch. If you want to enter the
> release process, don't integrate the new feature into the dev branch for
> the time being. Only modify the bug for the time being. Try to complete the
> big changes in the dev branch, not on the new release branch. Make big
> adjustments to minimize conflicts with dev.
> >> 2. After establishing a new release branch, all bug fixes should be
> guided to the new release branch as much as possible. It is recommended to
> add tags to the issue of the release branch to mark it. When it is merged,
> priority is also added to this part of pr to increase the community.
> Participation in publishing.
> >> 3. After creating a new release branch, allow the integration of large
> changes and new features, and if it is a bug fix on dev, try to lead to the
> release branch.
> >> 4. The changes of the release branch should be merged to the dev branch
> as soon as possible to avoid the difficulty of joining together later,
> because your own changes can easily determine which one should be merged if
> there is a conflict.
> >>
> >> ——————————————
> >> 现在发版分支管理面临问题如下:
> >> 1、发版参与率低，社区开发者很难，或者不太容易参与发版流程，主要是大家还是默认的把bug修复，新功能放到了dev分支，最终发版成了几个人的事情。
> >> 2、资源的浪费，同样一个bug，在发版分支和开发分支都做修改，浪费社区的精力和资源。
> >> 3、后期merge工作量大，发版周期可能持续很长，那这个时间段内冲突会很多，将来做合并的时候会很难取舍。
> >>
> >> 建议解决方案:
> >>
> 1、建立发版分支的时机，如果想进入发版流程，dev分支暂时不要合入新的feature，暂时只修改bug，尽量把大的改动都在dev分支完成，不要在新的发版分支上面做大的调整，尽可能减少和dev冲突部分。
> >> 2、建立新的发版分支后，所有bug
> fix都尽量引导到新的发版分支上，建议对发版分支的issue增加tag来标记，合入的时候也优先合入这部分pr，增加社区的发版参与度。
> >> 3、建立新的发版分支后，允许较大改动新功能的合入，并且如果是在dev上的bug fix尽量往发版分支上引导。
> >> 4、发版分支的改动，应该尽快merge到dev分支，避免后期一起合入的困难，因为自己的改动如果冲突很容易判断应该合入哪个，到最后的话会很难。
> >>
> >>
> >> Best Regards
> >> ---------------
> >> DolphinScheduler(Incubator) Committer
> >> Xiaochun Liu 刘小春
> >> liuxiaochun@apache.org
> >> ---------------
> >>
> >>
> >>
> >
> >
> >
> >
>
>
--
DolphinScheduler(Incubator) PPMC
Jun Gao 高俊
gaojun2048@gmail.com
Re: [SUGGESTION]Release branch management
Posted by Xiaochun Liu <li...@apache.org>.
@
> kezhenxu94
I mean the new bug fix PR can be merged into the release branch, more people can participate in release branch.
Best Regards
---------------
DolphinScheduler(Incubator) Committer
Xiaochun Liu 刘小春
liuxiaochun@apache.org
---------------
> 2020年5月13日 下午2:06，kezhenxu94@apache <ke...@apache.org> 写道：
>
>
> I’m totally confused why do you create a release branch if you’re going to continuously merge new codes into THIS release branch? IMO, “release branch” is for releasing and it aims to freeze the codes in some degree, new codes can be still merged into the “dev” branch, which doesn’t block the community. New codes can be merged into the “release branch” only when they’re critical in the Apache release process, license issues or branding problems, for example.
>
>
> GitHub @kezhenxu94, Opinions are my own
> Apache SkyWalking, Apache Dubbo
>
>
>> On May 13, 2020, at 13:43, Xiaochun Liu <li...@apache.org> wrote:
>>
>>
>> Hi, all
>>
>> We encountered the following problems in the release branch management:
>> 1. The release participation rate is low, it is difficult for community developers, or it is not easy to participate in the release process. It is mainly because everyone still fixes the bug by default, and the new features are placed in the dev branch. Finally, the release has become a matter of several people.
>> 2. The waste of resources, the same bug, is amended in the release branch and development branch, wasting the energy and resources of the community.
>> 3. The late merge workload is large, and the release cycle may last a long time. Then there will be a lot of conflicts in this period of time, and it will be difficult to choose when merging in the future.
>> recommended solution:
>> 1. Establish the timing of the release branch. If you want to enter the release process, don't integrate the new feature into the dev branch for the time being. Only modify the bug for the time being. Try to complete the big changes in the dev branch, not on the new release branch. Make big adjustments to minimize conflicts with dev.
>> 2. After establishing a new release branch, all bug fixes should be guided to the new release branch as much as possible. It is recommended to add tags to the issue of the release branch to mark it. When it is merged, priority is also added to this part of pr to increase the community. Participation in publishing.
>> 3. After creating a new release branch, allow the integration of large changes and new features, and if it is a bug fix on dev, try to lead to the release branch.
>> 4. The changes of the release branch should be merged to the dev branch as soon as possible to avoid the difficulty of joining together later, because your own changes can easily determine which one should be merged if there is a conflict.
>>
>> ——————————————
>> 现在发版分支管理面临问题如下:
>> 1、发版参与率低，社区开发者很难，或者不太容易参与发版流程，主要是大家还是默认的把bug修复，新功能放到了dev分支，最终发版成了几个人的事情。
>> 2、资源的浪费，同样一个bug，在发版分支和开发分支都做修改，浪费社区的精力和资源。
>> 3、后期merge工作量大，发版周期可能持续很长，那这个时间段内冲突会很多，将来做合并的时候会很难取舍。
>>
>> 建议解决方案:
>> 1、建立发版分支的时机，如果想进入发版流程，dev分支暂时不要合入新的feature，暂时只修改bug，尽量把大的改动都在dev分支完成，不要在新的发版分支上面做大的调整，尽可能减少和dev冲突部分。
>> 2、建立新的发版分支后，所有bug fix都尽量引导到新的发版分支上，建议对发版分支的issue增加tag来标记，合入的时候也优先合入这部分pr，增加社区的发版参与度。
>> 3、建立新的发版分支后，允许较大改动新功能的合入，并且如果是在dev上的bug fix尽量往发版分支上引导。
>> 4、发版分支的改动，应该尽快merge到dev分支，避免后期一起合入的困难，因为自己的改动如果冲突很容易判断应该合入哪个，到最后的话会很难。
>>
>>
>> Best Regards
>> ---------------
>> DolphinScheduler(Incubator) Committer
>> Xiaochun Liu 刘小春
>> liuxiaochun@apache.org
>> ---------------
>>
>>
>>
>
>
>
>
Re: [SUGGESTION]Release branch management
Posted by "kezhenxu94@apache" <ke...@apache.org>.
I’m totally confused why do you create a release branch if you’re going to continuously merge new codes into THIS release branch? IMO, “release branch” is for releasing and it aims to freeze the codes in some degree, new codes can be still merged into the “dev” branch, which doesn’t block the community. New codes can be merged into the “release branch” only when they’re critical in the Apache release process, license issues or branding problems, for example.
GitHub @kezhenxu94, Opinions are my own
Apache SkyWalking, Apache Dubbo
> On May 13, 2020, at 13:43, Xiaochun Liu <li...@apache.org> wrote:
>
>
> Hi, all
>
> We encountered the following problems in the release branch management:
> 1. The release participation rate is low, it is difficult for community developers, or it is not easy to participate in the release process. It is mainly because everyone still fixes the bug by default, and the new features are placed in the dev branch. Finally, the release has become a matter of several people.
> 2. The waste of resources, the same bug, is amended in the release branch and development branch, wasting the energy and resources of the community.
> 3. The late merge workload is large, and the release cycle may last a long time. Then there will be a lot of conflicts in this period of time, and it will be difficult to choose when merging in the future.
> recommended solution:
> 1. Establish the timing of the release branch. If you want to enter the release process, don't integrate the new feature into the dev branch for the time being. Only modify the bug for the time being. Try to complete the big changes in the dev branch, not on the new release branch. Make big adjustments to minimize conflicts with dev.
> 2. After establishing a new release branch, all bug fixes should be guided to the new release branch as much as possible. It is recommended to add tags to the issue of the release branch to mark it. When it is merged, priority is also added to this part of pr to increase the community. Participation in publishing.
> 3. After creating a new release branch, allow the integration of large changes and new features, and if it is a bug fix on dev, try to lead to the release branch.
> 4. The changes of the release branch should be merged to the dev branch as soon as possible to avoid the difficulty of joining together later, because your own changes can easily determine which one should be merged if there is a conflict.
>
> ——————————————
> 现在发版分支管理面临问题如下:
> 1、发版参与率低，社区开发者很难，或者不太容易参与发版流程，主要是大家还是默认的把bug修复，新功能放到了dev分支，最终发版成了几个人的事情。
> 2、资源的浪费，同样一个bug，在发版分支和开发分支都做修改，浪费社区的精力和资源。
> 3、后期merge工作量大，发版周期可能持续很长，那这个时间段内冲突会很多，将来做合并的时候会很难取舍。
>
> 建议解决方案:
> 1、建立发版分支的时机，如果想进入发版流程，dev分支暂时不要合入新的feature，暂时只修改bug，尽量把大的改动都在dev分支完成，不要在新的发版分支上面做大的调整，尽可能减少和dev冲突部分。
> 2、建立新的发版分支后，所有bug fix都尽量引导到新的发版分支上，建议对发版分支的issue增加tag来标记，合入的时候也优先合入这部分pr，增加社区的发版参与度。
> 3、建立新的发版分支后，允许较大改动新功能的合入，并且如果是在dev上的bug fix尽量往发版分支上引导。
> 4、发版分支的改动，应该尽快merge到dev分支，避免后期一起合入的困难，因为自己的改动如果冲突很容易判断应该合入哪个，到最后的话会很难。
>
>
> Best Regards
> ---------------
> DolphinScheduler(Incubator) Committer
> Xiaochun Liu 刘小春
> liuxiaochun@apache.org
> ---------------
>
>
>
Re: [SUGGESTION]Release branch management
Posted by liwenhe <li...@apache.org>.
Yeah, I agree with you.
We had better reduce PR during release, shouldn't integrate the new feature
into the dev branch, and we must ensure that release and dev branch should
be consistent.
If so, it will not be difficult to merge in the future.
Xiaochun Liu <li...@apache.org> 于2020年5月13日周三 下午1:43写道：
>
> Hi, all
>
> We encountered the following problems in the release branch management:
> 1. The release participation rate is low, it is difficult for community
> developers, or it is not easy to participate in the release process. It is
> mainly because everyone still fixes the bug by default, and the new
> features are placed in the dev branch. Finally, the release has become a
> matter of several people.
> 2. The waste of resources, the same bug, is amended in the release branch
> and development branch, wasting the energy and resources of the community.
> 3. The late merge workload is large, and the release cycle may last a long
> time. Then there will be a lot of conflicts in this period of time, and it
> will be difficult to choose when merging in the future.
>
> recommended solution:
> 1. Establish the timing of the release branch. If you want to enter the
> release process, don't integrate the new feature into the dev branch for
> the time being. Only modify the bug for the time being. Try to complete the
> big changes in the dev branch, not on the new release branch. Make big
> adjustments to minimize conflicts with dev.
> 2. After establishing a new release branch, all bug fixes should be guided
> to the new release branch as much as possible. It is recommended to add
> tags to the issue of the release branch to mark it. When it is merged,
> priority is also added to this part of pr to increase the community.
> Participation in publishing.
> 3. After creating a new release branch, allow the integration of large
> changes and new features, and if it is a bug fix on dev, try to lead to the
> release branch.
> 4. The changes of the release branch should be merged to the dev branch as
> soon as possible to avoid the difficulty of joining together later, because
> your own changes can easily determine which one should be merged if there
> is a conflict.
>
> ——————————————
> 现在发版分支管理面临问题如下:
> 1、发版参与率低，社区开发者很难，或者不太容易参与发版流程，主要是大家还是默认的把bug修复，新功能放到了dev分支，最终发版成了几个人的事情。
> 2、资源的浪费，同样一个bug，在发版分支和开发分支都做修改，浪费社区的精力和资源。
> 3、后期merge工作量大，发版周期可能持续很长，那这个时间段内冲突会很多，将来做合并的时候会很难取舍。
>
> 建议解决方案:
>
> 1、建立发版分支的时机，如果想进入发版流程，dev分支暂时不要合入新的feature，暂时只修改bug，尽量把大的改动都在dev分支完成，不要在新的发版分支上面做大的调整，尽可能减少和dev冲突部分。
> 2、建立新的发版分支后，所有bug
> fix都尽量引导到新的发版分支上，建议对发版分支的issue增加tag来标记，合入的时候也优先合入这部分pr，增加社区的发版参与度。
> 3、建立新的发版分支后，允许较大改动新功能的合入，并且如果是在dev上的bug fix尽量往发版分支上引导。
> 4、发版分支的改动，应该尽快merge到dev分支，避免后期一起合入的困难，因为自己的改动如果冲突很容易判断应该合入哪个，到最后的话会很难。
>
>
> Best Regards
> ---------------
> DolphinScheduler(Incubator) Committer
> Xiaochun Liu 刘小春
> liuxiaochun@apache.org
> ---------------
>
>
>
>