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 代立冬 [email protected] --------------- kezhenxu94@apache <[email protected]> 于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 <[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] > > --------------- > > > > > > > > > > >
