On Thu, Apr 19, 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.
+1 we should start to cut a new branch for release preparation. > > > > 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. > +1 the release cycles on different projects and different branches should be different :), and we should focus more on 2.6.x releases. > > > 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. > +1 but we should guarentee the compatibility between 2.6.x and 2.5.x before we announce EOL. > > > 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 > >
