Re: [DISCUSS] Dubbo Release schedule

[Ian Luo]

On Thu, Apr 19, 2018 at 10:22 AM, Jun Liu  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  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
>
>

Re: [DISCUSS] Dubbo Release schedule

[Ian Luo]

On Thu, Apr 19, 2018 at 11:48 AM, Huxing Zhang  wrote:

> Hi,
>
> On Thu, Apr 19, 2018 at 11:23 AM, Justin Mclean
>  wrote:
> > Hi,
> >
> >> It is not mandatory to change the project groupId to org.apache.dubbo in
> >> the first release. Is that right? We will finished it before graduating.
> >
> > It a good idea to change it but some Apache projects never change it as
> it would break too much existing user code.
> >
> > In Dubbo's case as the packages includes a companies name
> (com.alibaba.dubbo) rather than a product name IMO it would need to change
> at some point.
>
> Agreed.
>


Considering there's a fair huge user base in China, we should not change
the package name before the compatibility solution is ready, otherwise
people will refuse to upgrade Dubbo in their production environment since
it requires code change on their side, no matter how trivial the change
will be.



> >
> > If it was changed how much work would it be for existing users?
>
> Existing user will have to change the pom dependency.  IMO, these
> won't cost too much for end users.
>
> > Will it be more work for them it the change was done later?
>
> I don't think so. However, this will bring more work to us.
>
> Overall, I think changing the group id can't be done before the first
> release. We've already had a solution and it will be done before
> graduation.
>
>
> >
> > Thanks,
> > Justin
>
> --
> Best Regards！
> Huxing
>

Re: [DISCUSS] Dubbo Release schedule

[Yong Zhu]

hi, Justin

As John said in
https://lists.apache.org/thread.html/c4bc85049b02b179ef1c785b7c1a3d29c5832e389a93f2b0d91151a0@%3Cdev.dubbo.apache.org%3E

It is not mandatory to change the project groupId to org.apache.dubbo in
the first release. Is that right? We will finished it before graduating.

2018-04-19 8:48 GMT+08:00 Justin Mclean :

> Hi,
>
> > 0. Should we have release manager for these artifacts? Is there any
> > committer volunteer to be release manager?
>
> In general Apache project do have release managers.
>
> > 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.
>
> I would suggest making a release branch and not doing a code freeze as the
> release may take a little time to get right.
>
> One issue I’m concerned about is IP clearance [1] as that is likely to
> block the release.
>
> Thanks,
> Justin
>
> 1 https://issues.apache.org/jira/browse/DUBBO-3
>
>

Re: [DISCUSS] Dubbo Release schedule

[Jun Liu]

>> 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  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  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
> 

Re: [DISCUSS] Dubbo Release schedule

[Jun Liu]

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  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

Re: [DISCUSS] Dubbo Release schedule

[Von Gosling]

Hi,

> I would suggest making a release branch and not doing a code freeze as the 
> release may take a little time to get right.
> 
> One issue I’m concerned about is IP clearance [1] as that is likely to block 
> the release.

I would like to follow and double-check the IP clearance process, any block 
about here now ?



>> 0. Should we have release manager for these artifacts? Is there any
>> committer volunteer to be release manager?
> 
> In general Apache project do have release managers.


Yes. IMO, we’d better make clear the release process before we ask for the 
release manager, right ? Here is some hint[1] about release process from other 
Apache Project. 


[1] http://rocketmq.apache.org/docs/release-manual

Best Regards,
Von Gosling

> 在 2018年4月19日，08:48，Justin Mclean  写道：
> 
> Hi,
> 
>> 0. Should we have release manager for these artifacts? Is there any
>> committer volunteer to be release manager?
> 
> In general Apache project do have release managers.
> 
>> 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.
> 
> I would suggest making a release branch and not doing a code freeze as the 
> release may take a little time to get right.
> 
> One issue I’m concerned about is IP clearance [1] as that is likely to block 
> the release.
> 
> Thanks,
> Justin
> 
> 1 https://issues.apache.org/jira/browse/DUBBO-3
> 

Re: [DISCUSS] Dubbo Release schedule

[Justin Mclean]

Hi,

> 0. Should we have release manager for these artifacts? Is there any
> committer volunteer to be release manager?

In general Apache project do have release managers.

> 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.

I would suggest making a release branch and not doing a code freeze as the 
release may take a little time to get right.

One issue I’m concerned about is IP clearance [1] as that is likely to block 
the release.

Thanks,
Justin

1 https://issues.apache.org/jira/browse/DUBBO-3

Re: [DISCUSS] Dubbo Release schedule

[Huxing Zhang]

Ping.

On Thu, 12 Apr 2018 at 14:36, Huxing Zhang  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
>
-- 
Best Regards！
Huxing

[DISCUSS] Dubbo Release schedule

[Huxing Zhang]

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