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 <liuxiaoc...@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 刘小春 > liuxiaoc...@apache.org > --------------- > > > >
