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 代立冬 dailidon...@gmail.com --------------- JUN GAO <gaojun2...@gmail.com> 于2020年5月13日周三 下午3:33写道： > I agree with you ! > > Xiaochun Liu <liuxiaoc...@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 刘小春 > > 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 > > >> --------------- > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > -- > > DolphinScheduler(Incubator) PPMC > Jun Gao 高俊 > gaojun2...@gmail.com >
