>> 2. What should be included in the 2.6.x release? My suggestion is >> label the issues and pull request with a milestone like >> "2.6.2-release”. > > +1 milestone, every committer should check the milestone before a merge or > commit. > Actually, we already have a milestone ‘2.6.2’ tracking issues for this > release, only not maintained in time. let me check all the commits and make > sure every one being tracked with a issue labeled with 2.6.2 milestone.
BTW, check expected to be done by this week. > On 19 Apr 2018, at 10:22 AM, Jun Liu <liu...@apache.org> wrote: > > Hi ALL, > >> 0. Should we have release manager for these artifacts? Is there any >> committer volunteer to be release manager? > > Fortunately, haven't missed this release yet. I’d like to be the release > manager for the first apache release. > >> 1. Should we keep the release cycle for 2.6.x? Our first Apache >> release might take some time because we have bunch of things to do >> [1][2][3]. If we need to do keep it, we'd better enter code freeze >> soon as start to prepare for the release. > > Agree with Justin’s solution, create a new branch for the first release, not > freeze the master branch, as it may take some time. > >> 2. What should be included in the 2.6.x release? My suggestion is >> label the issues and pull request with a milestone like >> "2.6.2-release”. > > +1 milestone, every committer should check the milestone before a merge or > commit. > Actually, we already have a milestone ‘2.6.2’ tracking issues for this > release, only not maintained in time. let me check all the commits and make > sure every one being tracked with a issue labeled with 2.6.2 milestone. > >> 3. Should we have a release cycle for 2.5.x and >> dubbo-spring-boot-starter? If we do, what the release cycle is? > > My suggestion, no need of release cycle for 2.5.x and boot-starter. > Especially for 2.5.x, release whenever it’s needed, usually when reported > with important bugs. > >> 4. Should we stop accepting new pull request while we are preparing >> the release? Since 2.6.x is on the master branch, if we are working on >> that branch for release, new pull request won't be able to come in. > > A temporary release branch can resolve. > >> 5. Should we keep maintaining 2.5.x branch forever? Or do we have an >> end of life of 2.5.x and encourage people to migrate to 2.6.x? > > > Currently, 2.6.x is the recommend release. > We will announce EOL some day. > >> On 12 Apr 2018, at 2:36 PM, Huxing Zhang <hux...@apache.org> wrote: >> >> Hi All, >> >> For now, the dubbo community have three release artifact: >> 1. dubbo 2.6.x >> 2. dubbo 2.5.x >> 3. dubbo-spring-boot-starter >> >> The release cycle of 2.6.x is roughly a month, while 2.5.x is >> uncertain because it is a maintenance branch that only accept bugfix. >> >> dubbo-spring-boot-starter only have 1 release until now, and depends >> on the dubbo 2.6.x. >> >> Since we are going to have our first Apache release, I have a couple >> of questions and would like to discuss with the community: >> >> 0. Should we have release manager for these artifacts? Is there any >> committer volunteer to be release manager? >> >> 1. Should we keep the release cycle for 2.6.x? Our first Apache >> release might take some time because we have bunch of things to do >> [1][2][3]. If we need to do keep it, we'd better enter code freeze >> soon as start to prepare for the release. >> >> 2. What should be included in the 2.6.x release? My suggestion is >> label the issues and pull request with a milestone like >> "2.6.2-release". >> >> 3. Should we have a release cycle for 2.5.x and >> dubbo-spring-boot-starter? If we do, what the release cycle is? >> >> 4. Should we stop accepting new pull request while we are preparing >> the release? Since 2.6.x is on the master branch, if we are working on >> that branch for release, new pull request won't be able to come in. >> >> 5. Should we keep maintaining 2.5.x branch forever? Or do we have an >> end of life of 2.5.x and encourage people to migrate to 2.6.x? >> >> [1] http://www.apache.org/dev/#releases >> [2] https://incubator.apache.org/guides/releasemanagement.html >> [3] https://rocketmq.apache.org/docs/release-manual >> >> -- >> Best Regards！ >> Huxing >
