@ > 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 刘小春 liuxiaoc...@apache.org --------------- > 2020年5月13日 下午2:06，kezhenxu94@apache <kezhenx...@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 <liuxiaoc...@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 刘小春 >> liuxiaoc...@apache.org >> --------------- >> >> >> > > > >
