I agree with you ! Xiaochun Liu <[email protected]> 于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 刘小春 > [email protected] > --------------- > > > > > 2020年5月13日 下午2:06，kezhenxu94@apache <[email protected]> 写道： > > > > > > 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 <[email protected]> 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 刘小春 > >> [email protected] > >> --------------- > >> > >> > >> > > > > > > > > > > -- DolphinScheduler(Incubator) PPMC Jun Gao 高俊 [email protected]
