You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@echarts.apache.org by SHUANG SU <su...@gmail.com> on 2019/08/26 08:04:03 UTC
Fwd: [DISCUSS] Changelog issue
------------------------------
Su Shuang (100pah)
------------------------------
---------- Forwarded message ---------
From: SHUANG SU <su...@gmail.com>
Date: Mon, 26 Aug 2019 at 15:56
Subject: [DISCUSS] Changelog issue
To: <pr...@echarts.apache.org>
Hi all,
Shall we discuss a changelog issue:
Suppose we have these versions:
4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==> 4.2.1(formal release)
The changelog of 4.2.1, should be:
A. The diff with 4.1.0
(where the major part of the changelog of 4.2.1 will be duplicated
with the changelog of 4.2.1-rc.1)
B. The diff with 4.2.1-rc.1
(where the changelog of 4.2.1 will contain only a little content,
that is probably not appropriate for a "formal release")
------------------------------
Su Shuang (100pah)
------------------------------
Re: [DISCUSS] Changelog issue
Posted by Sheng Wu <wu...@gmail.com>.
The release version model is totally based on the community itself.
Apache says nothing about it, only basic tradition is, don't change the
content if you are doing release test and vote.
Sheng Wu 吴晟
Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
Twitter, wusheng1108
SHUANG SU <su...@gmail.com> 于2019年8月26日周一 下午4:32写道：
> > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
> not contain new features or fix bugs. They should only fix release-related
> problems like license problems.
>
> I agree with that.
>
> > Even if there is an urgent issue, we should start a new hotfix version
> rather than adding it in another release candidate.
>
> I am afraid I don't agree with that.
> For example, if we are in the procedure of release v4.3.0, the current
> version that
> is public testing is v4.3.0.rc-1, and a bug is found in this version.
> If we fix this bug and immediately start a new hotfix version naming
> v4.3.1, we will have no v4.3.0 any more.
> If we publish v4.3.0 with the serious bug not fixed, and start a new hotfix
> version naming v4.3.1,
> the v4.3.0 probably harm users.
>
>
>
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
>
> On Mon, 26 Aug 2019 at 16:17, Ovilia <ov...@gmail.com> wrote:
>
> > I think it should be the changelog since the last formal release.
> >
> > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
> > not contain new features or fix bugs. They should only fix
> release-related
> > problems like license problems.
> > Even if there is an urgent issue, we should start a new hotfix version
> > rather than adding it in another release candidate.
> >
> > Perhaps we should also discuss our version number policy in this thread.
> > A popular method may be MAJOR.MINOR.PATCH [1].
> > In this case, we may add the minor version in each regular monthly
> release,
> > and use patch number to version hotfix versions.
> >
> > Apache release policy [2] doesn't talk too much about whether release
> > candidates could include new features or new bug fixes. Could our mentor
> > give any advice on this?
> >
> > [1] https://semver.org/
> > [2] http://www.apache.org/legal/release-policy.html
> >
> > Wenli
> >
> >
> > On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com>
> wrote:
> >
> > > ------------------------------
> > > Su Shuang (100pah)
> > > ------------------------------
> > >
> > >
> > >
> > > ---------- Forwarded message ---------
> > > From: SHUANG SU <su...@gmail.com>
> > > Date: Mon, 26 Aug 2019 at 15:56
> > > Subject: [DISCUSS] Changelog issue
> > > To: <pr...@echarts.apache.org>
> > >
> > >
> > >
> > > Hi all,
> > >
> > > Shall we discuss a changelog issue:
> > >
> > > Suppose we have these versions:
> > > 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==> 4.2.1(formal
> > release)
> > >
> > > The changelog of 4.2.1, should be:
> > > A. The diff with 4.1.0
> > > (where the major part of the changelog of 4.2.1 will be
> duplicated
> > > with the changelog of 4.2.1-rc.1)
> > > B. The diff with 4.2.1-rc.1
> > > (where the changelog of 4.2.1 will contain only a little content,
> > > that is probably not appropriate for a "formal release")
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------
> > > Su Shuang (100pah)
> > > ------------------------------
> > >
> >
>
Re: [DISCUSS] Changelog issue
Posted by Willem Ning Jiang <ni...@apache.org>.
I think it dependents on the if we release the version.
Normally, if we find some bug on rc version before publishing the official release, we could just abandon the version. But if you already publish the official release, we'd better keep the changelog as it.
Does that make sense?
On 2019/08/26 08:32:04, SHUANG SU <su...@gmail.com> wrote:
> > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
> not contain new features or fix bugs. They should only fix release-related
> problems like license problems.
>
> I agree with that.
>
> > Even if there is an urgent issue, we should start a new hotfix version
> rather than adding it in another release candidate.
>
> I am afraid I don't agree with that.
> For example, if we are in the procedure of release v4.3.0, the current
> version that
> is public testing is v4.3.0.rc-1, and a bug is found in this version.
> If we fix this bug and immediately start a new hotfix version naming
> v4.3.1, we will have no v4.3.0 any more.
> If we publish v4.3.0 with the serious bug not fixed, and start a new hotfix
> version naming v4.3.1,
> the v4.3.0 probably harm users.
>
>
>
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
>
> On Mon, 26 Aug 2019 at 16:17, Ovilia <ov...@gmail.com> wrote:
>
> > I think it should be the changelog since the last formal release.
> >
> > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
> > not contain new features or fix bugs. They should only fix release-related
> > problems like license problems.
> > Even if there is an urgent issue, we should start a new hotfix version
> > rather than adding it in another release candidate.
> >
> > Perhaps we should also discuss our version number policy in this thread.
> > A popular method may be MAJOR.MINOR.PATCH [1].
> > In this case, we may add the minor version in each regular monthly release,
> > and use patch number to version hotfix versions.
> >
> > Apache release policy [2] doesn't talk too much about whether release
> > candidates could include new features or new bug fixes. Could our mentor
> > give any advice on this?
> >
> > [1] https://semver.org/
> > [2] http://www.apache.org/legal/release-policy.html
> >
> > Wenli
> >
> >
> > On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com> wrote:
> >
> > > ------------------------------
> > > Su Shuang (100pah)
> > > ------------------------------
> > >
> > >
> > >
> > > ---------- Forwarded message ---------
> > > From: SHUANG SU <su...@gmail.com>
> > > Date: Mon, 26 Aug 2019 at 15:56
> > > Subject: [DISCUSS] Changelog issue
> > > To: <pr...@echarts.apache.org>
> > >
> > >
> > >
> > > Hi all,
> > >
> > > Shall we discuss a changelog issue:
> > >
> > > Suppose we have these versions:
> > > 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==> 4.2.1(formal
> > release)
> > >
> > > The changelog of 4.2.1, should be:
> > > A. The diff with 4.1.0
> > > (where the major part of the changelog of 4.2.1 will be duplicated
> > > with the changelog of 4.2.1-rc.1)
> > > B. The diff with 4.2.1-rc.1
> > > (where the changelog of 4.2.1 will contain only a little content,
> > > that is probably not appropriate for a "formal release")
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------
> > > Su Shuang (100pah)
> > > ------------------------------
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@echarts.apache.org
For additional commands, e-mail: dev-help@echarts.apache.org
Re: [DISCUSS] Changelog issue
Posted by Willem Ning Jiang <ni...@apache.org>.
I cannot agree with you more.
Open Source means openness and collaboration.
In Apache we build the consensus[1] through discussion by making proposals and eliciting responses and let the best idea win.
[1]https://community.apache.org/committers/consensusBuilding.html
On 2019/08/26 13:05:07, SHUANG SU <su...@gmail.com> wrote:
> > I think if this is the Apache way, we should respect and apply to that,
> rather than referencing how other open-source projects do.
>
> Only about this statement, I don't agree with that.
> I think Apache way is formed and has been evolving over time via lots of
> discussions,
> but not some literal rules that we obey them but do not know why.
>
> About the voting process, theoretically, people should not only check the
> license issues but also check the quality of the release.
> If some defects about the license found, fix them and start a new vote.
> If some defects about the code itself found, we should also fix them and
> start a new vote.
> We are releasing "source code", which not only contains the license but
> also contain
> the code itself. So I think all of them can be modified, and start a new
> vote.
> The final vote is targeting at the final code containing all of the fixes.
> Once it is voted
> though, the code should not be modified anymore.
>
>
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
>
> On Mon, 26 Aug 2019 at 17:33, Ovilia <ov...@gmail.com> wrote:
>
> > Just to clarify, when Sheng Wu said that content should remain the same,
> > does it mean the source code should remain the same (except for fixing
> > license problem?) as the first release candidate?
> >
> > I think if this is the Apache way, we should respect and apply to that,
> > rather than referencing how other open-source projects do.
> >
> > Wenli
> >
> >
> > On Mon, Aug 26, 2019 at 5:28 PM Yi Shen <sh...@gmail.com> wrote:
> >
> > > I checked angular's changelog[1] . They also have several bug fixes in
> > the
> > > release candidate(for example 8.0.0-rc). And the changelog of formal
> > > version(8.0.0) seems contains all the changes in the previous beta,
> > release
> > > candidate versions.
> > >
> > > I believe it's more reasonable if the changelog is since the last formal
> > > release.
> > >
> > > [1] https://github.com/angular/angular/blob/master/CHANGELOG.md
> > >
> > > On Mon, Aug 26, 2019 at 5:03 PM Ovilia <ov...@gmail.com> wrote:
> > >
> > > > > If we fix this bug and immediately start a new hotfix version naming
> > > > v4.3.1, we will have no v4.3.0 any more.
> > > >
> > > > If the problem is really dangerous, maybe we should abandon this
> > version.
> > > >
> > > > The main consideration is to keep the content unchanged, as Sheng Wu
> > > said.
> > > > In fact, this has already caused a few confusions in the community now.
> > > > When reporting issues, we ask them to provide the version number, but
> > the
> > > > version number in the source code doesn't contain release candidate
> > > number
> > > > like 'rc1'. This may cause confusion when it's about a bug fixed in an
> > rc
> > > > version.
> > > >
> > > > Wenli
> > > >
> > > >
> > > > On Mon, Aug 26, 2019 at 4:32 PM SHUANG SU <su...@gmail.com>
> > > wrote:
> > > >
> > > > > > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...)
> > > > should
> > > > > not contain new features or fix bugs. They should only fix
> > > > release-related
> > > > > problems like license problems.
> > > > >
> > > > > I agree with that.
> > > > >
> > > > > > Even if there is an urgent issue, we should start a new hotfix
> > > version
> > > > > rather than adding it in another release candidate.
> > > > >
> > > > > I am afraid I don't agree with that.
> > > > > For example, if we are in the procedure of release v4.3.0, the
> > current
> > > > > version that
> > > > > is public testing is v4.3.0.rc-1, and a bug is found in this version.
> > > > > If we fix this bug and immediately start a new hotfix version naming
> > > > > v4.3.1, we will have no v4.3.0 any more.
> > > > > If we publish v4.3.0 with the serious bug not fixed, and start a new
> > > > hotfix
> > > > > version naming v4.3.1,
> > > > > the v4.3.0 probably harm users.
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------
> > > > > Su Shuang (100pah)
> > > > > ------------------------------
> > > > >
> > > > >
> > > > >
> > > > > On Mon, 26 Aug 2019 at 16:17, Ovilia <ov...@gmail.com> wrote:
> > > > >
> > > > > > I think it should be the changelog since the last formal release.
> > > > > >
> > > > > > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...)
> > > > should
> > > > > > not contain new features or fix bugs. They should only fix
> > > > > release-related
> > > > > > problems like license problems.
> > > > > > Even if there is an urgent issue, we should start a new hotfix
> > > version
> > > > > > rather than adding it in another release candidate.
> > > > > >
> > > > > > Perhaps we should also discuss our version number policy in this
> > > > thread.
> > > > > > A popular method may be MAJOR.MINOR.PATCH [1].
> > > > > > In this case, we may add the minor version in each regular monthly
> > > > > release,
> > > > > > and use patch number to version hotfix versions.
> > > > > >
> > > > > > Apache release policy [2] doesn't talk too much about whether
> > release
> > > > > > candidates could include new features or new bug fixes. Could our
> > > > mentor
> > > > > > give any advice on this?
> > > > > >
> > > > > > [1] https://semver.org/
> > > > > > [2] http://www.apache.org/legal/release-policy.html
> > > > > >
> > > > > > Wenli
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > ------------------------------
> > > > > > > Su Shuang (100pah)
> > > > > > > ------------------------------
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ---------- Forwarded message ---------
> > > > > > > From: SHUANG SU <su...@gmail.com>
> > > > > > > Date: Mon, 26 Aug 2019 at 15:56
> > > > > > > Subject: [DISCUSS] Changelog issue
> > > > > > > To: <pr...@echarts.apache.org>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Shall we discuss a changelog issue:
> > > > > > >
> > > > > > > Suppose we have these versions:
> > > > > > > 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==>
> > 4.2.1(formal
> > > > > > release)
> > > > > > >
> > > > > > > The changelog of 4.2.1, should be:
> > > > > > > A. The diff with 4.1.0
> > > > > > > (where the major part of the changelog of 4.2.1 will be
> > > > > duplicated
> > > > > > > with the changelog of 4.2.1-rc.1)
> > > > > > > B. The diff with 4.2.1-rc.1
> > > > > > > (where the changelog of 4.2.1 will contain only a little
> > > > content,
> > > > > > > that is probably not appropriate for a "formal release")
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ------------------------------
> > > > > > > Su Shuang (100pah)
> > > > > > > ------------------------------
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Yi Shen
> > > Senior Developer
> > > Baidu, Inc.
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@echarts.apache.org
For additional commands, e-mail: dev-help@echarts.apache.org
Re: [DISCUSS] Changelog issue
Posted by SHUANG SU <su...@gmail.com>.
> I think if this is the Apache way, we should respect and apply to that,
rather than referencing how other open-source projects do.
Only about this statement, I don't agree with that.
I think Apache way is formed and has been evolving over time via lots of
discussions,
but not some literal rules that we obey them but do not know why.
About the voting process, theoretically, people should not only check the
license issues but also check the quality of the release.
If some defects about the license found, fix them and start a new vote.
If some defects about the code itself found, we should also fix them and
start a new vote.
We are releasing "source code", which not only contains the license but
also contain
the code itself. So I think all of them can be modified, and start a new
vote.
The final vote is targeting at the final code containing all of the fixes.
Once it is voted
though, the code should not be modified anymore.
------------------------------
Su Shuang (100pah)
------------------------------
On Mon, 26 Aug 2019 at 17:33, Ovilia <ov...@gmail.com> wrote:
> Just to clarify, when Sheng Wu said that content should remain the same,
> does it mean the source code should remain the same (except for fixing
> license problem?) as the first release candidate?
>
> I think if this is the Apache way, we should respect and apply to that,
> rather than referencing how other open-source projects do.
>
> Wenli
>
>
> On Mon, Aug 26, 2019 at 5:28 PM Yi Shen <sh...@gmail.com> wrote:
>
> > I checked angular's changelog[1] . They also have several bug fixes in
> the
> > release candidate(for example 8.0.0-rc). And the changelog of formal
> > version(8.0.0) seems contains all the changes in the previous beta,
> release
> > candidate versions.
> >
> > I believe it's more reasonable if the changelog is since the last formal
> > release.
> >
> > [1] https://github.com/angular/angular/blob/master/CHANGELOG.md
> >
> > On Mon, Aug 26, 2019 at 5:03 PM Ovilia <ov...@gmail.com> wrote:
> >
> > > > If we fix this bug and immediately start a new hotfix version naming
> > > v4.3.1, we will have no v4.3.0 any more.
> > >
> > > If the problem is really dangerous, maybe we should abandon this
> version.
> > >
> > > The main consideration is to keep the content unchanged, as Sheng Wu
> > said.
> > > In fact, this has already caused a few confusions in the community now.
> > > When reporting issues, we ask them to provide the version number, but
> the
> > > version number in the source code doesn't contain release candidate
> > number
> > > like 'rc1'. This may cause confusion when it's about a bug fixed in an
> rc
> > > version.
> > >
> > > Wenli
> > >
> > >
> > > On Mon, Aug 26, 2019 at 4:32 PM SHUANG SU <su...@gmail.com>
> > wrote:
> > >
> > > > > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...)
> > > should
> > > > not contain new features or fix bugs. They should only fix
> > > release-related
> > > > problems like license problems.
> > > >
> > > > I agree with that.
> > > >
> > > > > Even if there is an urgent issue, we should start a new hotfix
> > version
> > > > rather than adding it in another release candidate.
> > > >
> > > > I am afraid I don't agree with that.
> > > > For example, if we are in the procedure of release v4.3.0, the
> current
> > > > version that
> > > > is public testing is v4.3.0.rc-1, and a bug is found in this version.
> > > > If we fix this bug and immediately start a new hotfix version naming
> > > > v4.3.1, we will have no v4.3.0 any more.
> > > > If we publish v4.3.0 with the serious bug not fixed, and start a new
> > > hotfix
> > > > version naming v4.3.1,
> > > > the v4.3.0 probably harm users.
> > > >
> > > >
> > > >
> > > > ------------------------------
> > > > Su Shuang (100pah)
> > > > ------------------------------
> > > >
> > > >
> > > >
> > > > On Mon, 26 Aug 2019 at 16:17, Ovilia <ov...@gmail.com> wrote:
> > > >
> > > > > I think it should be the changelog since the last formal release.
> > > > >
> > > > > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...)
> > > should
> > > > > not contain new features or fix bugs. They should only fix
> > > > release-related
> > > > > problems like license problems.
> > > > > Even if there is an urgent issue, we should start a new hotfix
> > version
> > > > > rather than adding it in another release candidate.
> > > > >
> > > > > Perhaps we should also discuss our version number policy in this
> > > thread.
> > > > > A popular method may be MAJOR.MINOR.PATCH [1].
> > > > > In this case, we may add the minor version in each regular monthly
> > > > release,
> > > > > and use patch number to version hotfix versions.
> > > > >
> > > > > Apache release policy [2] doesn't talk too much about whether
> release
> > > > > candidates could include new features or new bug fixes. Could our
> > > mentor
> > > > > give any advice on this?
> > > > >
> > > > > [1] https://semver.org/
> > > > > [2] http://www.apache.org/legal/release-policy.html
> > > > >
> > > > > Wenli
> > > > >
> > > > >
> > > > > On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > ------------------------------
> > > > > > Su Shuang (100pah)
> > > > > > ------------------------------
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------- Forwarded message ---------
> > > > > > From: SHUANG SU <su...@gmail.com>
> > > > > > Date: Mon, 26 Aug 2019 at 15:56
> > > > > > Subject: [DISCUSS] Changelog issue
> > > > > > To: <pr...@echarts.apache.org>
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Shall we discuss a changelog issue:
> > > > > >
> > > > > > Suppose we have these versions:
> > > > > > 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==>
> 4.2.1(formal
> > > > > release)
> > > > > >
> > > > > > The changelog of 4.2.1, should be:
> > > > > > A. The diff with 4.1.0
> > > > > > (where the major part of the changelog of 4.2.1 will be
> > > > duplicated
> > > > > > with the changelog of 4.2.1-rc.1)
> > > > > > B. The diff with 4.2.1-rc.1
> > > > > > (where the changelog of 4.2.1 will contain only a little
> > > content,
> > > > > > that is probably not appropriate for a "formal release")
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ------------------------------
> > > > > > Su Shuang (100pah)
> > > > > > ------------------------------
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Yi Shen
> > Senior Developer
> > Baidu, Inc.
> >
>
Re: [DISCUSS] Changelog issue
Posted by Ovilia <ov...@gmail.com>.
Just to clarify, when Sheng Wu said that content should remain the same,
does it mean the source code should remain the same (except for fixing
license problem?) as the first release candidate?
I think if this is the Apache way, we should respect and apply to that,
rather than referencing how other open-source projects do.
Wenli
On Mon, Aug 26, 2019 at 5:28 PM Yi Shen <sh...@gmail.com> wrote:
> I checked angular's changelog[1] . They also have several bug fixes in the
> release candidate(for example 8.0.0-rc). And the changelog of formal
> version(8.0.0) seems contains all the changes in the previous beta, release
> candidate versions.
>
> I believe it's more reasonable if the changelog is since the last formal
> release.
>
> [1] https://github.com/angular/angular/blob/master/CHANGELOG.md
>
> On Mon, Aug 26, 2019 at 5:03 PM Ovilia <ov...@gmail.com> wrote:
>
> > > If we fix this bug and immediately start a new hotfix version naming
> > v4.3.1, we will have no v4.3.0 any more.
> >
> > If the problem is really dangerous, maybe we should abandon this version.
> >
> > The main consideration is to keep the content unchanged, as Sheng Wu
> said.
> > In fact, this has already caused a few confusions in the community now.
> > When reporting issues, we ask them to provide the version number, but the
> > version number in the source code doesn't contain release candidate
> number
> > like 'rc1'. This may cause confusion when it's about a bug fixed in an rc
> > version.
> >
> > Wenli
> >
> >
> > On Mon, Aug 26, 2019 at 4:32 PM SHUANG SU <su...@gmail.com>
> wrote:
> >
> > > > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...)
> > should
> > > not contain new features or fix bugs. They should only fix
> > release-related
> > > problems like license problems.
> > >
> > > I agree with that.
> > >
> > > > Even if there is an urgent issue, we should start a new hotfix
> version
> > > rather than adding it in another release candidate.
> > >
> > > I am afraid I don't agree with that.
> > > For example, if we are in the procedure of release v4.3.0, the current
> > > version that
> > > is public testing is v4.3.0.rc-1, and a bug is found in this version.
> > > If we fix this bug and immediately start a new hotfix version naming
> > > v4.3.1, we will have no v4.3.0 any more.
> > > If we publish v4.3.0 with the serious bug not fixed, and start a new
> > hotfix
> > > version naming v4.3.1,
> > > the v4.3.0 probably harm users.
> > >
> > >
> > >
> > > ------------------------------
> > > Su Shuang (100pah)
> > > ------------------------------
> > >
> > >
> > >
> > > On Mon, 26 Aug 2019 at 16:17, Ovilia <ov...@gmail.com> wrote:
> > >
> > > > I think it should be the changelog since the last formal release.
> > > >
> > > > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...)
> > should
> > > > not contain new features or fix bugs. They should only fix
> > > release-related
> > > > problems like license problems.
> > > > Even if there is an urgent issue, we should start a new hotfix
> version
> > > > rather than adding it in another release candidate.
> > > >
> > > > Perhaps we should also discuss our version number policy in this
> > thread.
> > > > A popular method may be MAJOR.MINOR.PATCH [1].
> > > > In this case, we may add the minor version in each regular monthly
> > > release,
> > > > and use patch number to version hotfix versions.
> > > >
> > > > Apache release policy [2] doesn't talk too much about whether release
> > > > candidates could include new features or new bug fixes. Could our
> > mentor
> > > > give any advice on this?
> > > >
> > > > [1] https://semver.org/
> > > > [2] http://www.apache.org/legal/release-policy.html
> > > >
> > > > Wenli
> > > >
> > > >
> > > > On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com>
> > > wrote:
> > > >
> > > > > ------------------------------
> > > > > Su Shuang (100pah)
> > > > > ------------------------------
> > > > >
> > > > >
> > > > >
> > > > > ---------- Forwarded message ---------
> > > > > From: SHUANG SU <su...@gmail.com>
> > > > > Date: Mon, 26 Aug 2019 at 15:56
> > > > > Subject: [DISCUSS] Changelog issue
> > > > > To: <pr...@echarts.apache.org>
> > > > >
> > > > >
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Shall we discuss a changelog issue:
> > > > >
> > > > > Suppose we have these versions:
> > > > > 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==> 4.2.1(formal
> > > > release)
> > > > >
> > > > > The changelog of 4.2.1, should be:
> > > > > A. The diff with 4.1.0
> > > > > (where the major part of the changelog of 4.2.1 will be
> > > duplicated
> > > > > with the changelog of 4.2.1-rc.1)
> > > > > B. The diff with 4.2.1-rc.1
> > > > > (where the changelog of 4.2.1 will contain only a little
> > content,
> > > > > that is probably not appropriate for a "formal release")
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------
> > > > > Su Shuang (100pah)
> > > > > ------------------------------
> > > > >
> > > >
> > >
> >
>
>
> --
> Yi Shen
> Senior Developer
> Baidu, Inc.
>
Re: [DISCUSS] Changelog issue
Posted by Yi Shen <sh...@gmail.com>.
I checked angular's changelog[1] . They also have several bug fixes in the
release candidate(for example 8.0.0-rc). And the changelog of formal
version(8.0.0) seems contains all the changes in the previous beta, release
candidate versions.
I believe it's more reasonable if the changelog is since the last formal
release.
[1] https://github.com/angular/angular/blob/master/CHANGELOG.md
On Mon, Aug 26, 2019 at 5:03 PM Ovilia <ov...@gmail.com> wrote:
> > If we fix this bug and immediately start a new hotfix version naming
> v4.3.1, we will have no v4.3.0 any more.
>
> If the problem is really dangerous, maybe we should abandon this version.
>
> The main consideration is to keep the content unchanged, as Sheng Wu said.
> In fact, this has already caused a few confusions in the community now.
> When reporting issues, we ask them to provide the version number, but the
> version number in the source code doesn't contain release candidate number
> like 'rc1'. This may cause confusion when it's about a bug fixed in an rc
> version.
>
> Wenli
>
>
> On Mon, Aug 26, 2019 at 4:32 PM SHUANG SU <su...@gmail.com> wrote:
>
> > > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...)
> should
> > not contain new features or fix bugs. They should only fix
> release-related
> > problems like license problems.
> >
> > I agree with that.
> >
> > > Even if there is an urgent issue, we should start a new hotfix version
> > rather than adding it in another release candidate.
> >
> > I am afraid I don't agree with that.
> > For example, if we are in the procedure of release v4.3.0, the current
> > version that
> > is public testing is v4.3.0.rc-1, and a bug is found in this version.
> > If we fix this bug and immediately start a new hotfix version naming
> > v4.3.1, we will have no v4.3.0 any more.
> > If we publish v4.3.0 with the serious bug not fixed, and start a new
> hotfix
> > version naming v4.3.1,
> > the v4.3.0 probably harm users.
> >
> >
> >
> > ------------------------------
> > Su Shuang (100pah)
> > ------------------------------
> >
> >
> >
> > On Mon, 26 Aug 2019 at 16:17, Ovilia <ov...@gmail.com> wrote:
> >
> > > I think it should be the changelog since the last formal release.
> > >
> > > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...)
> should
> > > not contain new features or fix bugs. They should only fix
> > release-related
> > > problems like license problems.
> > > Even if there is an urgent issue, we should start a new hotfix version
> > > rather than adding it in another release candidate.
> > >
> > > Perhaps we should also discuss our version number policy in this
> thread.
> > > A popular method may be MAJOR.MINOR.PATCH [1].
> > > In this case, we may add the minor version in each regular monthly
> > release,
> > > and use patch number to version hotfix versions.
> > >
> > > Apache release policy [2] doesn't talk too much about whether release
> > > candidates could include new features or new bug fixes. Could our
> mentor
> > > give any advice on this?
> > >
> > > [1] https://semver.org/
> > > [2] http://www.apache.org/legal/release-policy.html
> > >
> > > Wenli
> > >
> > >
> > > On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com>
> > wrote:
> > >
> > > > ------------------------------
> > > > Su Shuang (100pah)
> > > > ------------------------------
> > > >
> > > >
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: SHUANG SU <su...@gmail.com>
> > > > Date: Mon, 26 Aug 2019 at 15:56
> > > > Subject: [DISCUSS] Changelog issue
> > > > To: <pr...@echarts.apache.org>
> > > >
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > Shall we discuss a changelog issue:
> > > >
> > > > Suppose we have these versions:
> > > > 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==> 4.2.1(formal
> > > release)
> > > >
> > > > The changelog of 4.2.1, should be:
> > > > A. The diff with 4.1.0
> > > > (where the major part of the changelog of 4.2.1 will be
> > duplicated
> > > > with the changelog of 4.2.1-rc.1)
> > > > B. The diff with 4.2.1-rc.1
> > > > (where the changelog of 4.2.1 will contain only a little
> content,
> > > > that is probably not appropriate for a "formal release")
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ------------------------------
> > > > Su Shuang (100pah)
> > > > ------------------------------
> > > >
> > >
> >
>
--
Yi Shen
Senior Developer
Baidu, Inc.
Re: [DISCUSS] Changelog issue
Posted by Ovilia <ov...@gmail.com>.
> If we fix this bug and immediately start a new hotfix version naming
v4.3.1, we will have no v4.3.0 any more.
If the problem is really dangerous, maybe we should abandon this version.
The main consideration is to keep the content unchanged, as Sheng Wu said.
In fact, this has already caused a few confusions in the community now.
When reporting issues, we ask them to provide the version number, but the
version number in the source code doesn't contain release candidate number
like 'rc1'. This may cause confusion when it's about a bug fixed in an rc
version.
Wenli
On Mon, Aug 26, 2019 at 4:32 PM SHUANG SU <su...@gmail.com> wrote:
> > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
> not contain new features or fix bugs. They should only fix release-related
> problems like license problems.
>
> I agree with that.
>
> > Even if there is an urgent issue, we should start a new hotfix version
> rather than adding it in another release candidate.
>
> I am afraid I don't agree with that.
> For example, if we are in the procedure of release v4.3.0, the current
> version that
> is public testing is v4.3.0.rc-1, and a bug is found in this version.
> If we fix this bug and immediately start a new hotfix version naming
> v4.3.1, we will have no v4.3.0 any more.
> If we publish v4.3.0 with the serious bug not fixed, and start a new hotfix
> version naming v4.3.1,
> the v4.3.0 probably harm users.
>
>
>
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
>
> On Mon, 26 Aug 2019 at 16:17, Ovilia <ov...@gmail.com> wrote:
>
> > I think it should be the changelog since the last formal release.
> >
> > In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
> > not contain new features or fix bugs. They should only fix
> release-related
> > problems like license problems.
> > Even if there is an urgent issue, we should start a new hotfix version
> > rather than adding it in another release candidate.
> >
> > Perhaps we should also discuss our version number policy in this thread.
> > A popular method may be MAJOR.MINOR.PATCH [1].
> > In this case, we may add the minor version in each regular monthly
> release,
> > and use patch number to version hotfix versions.
> >
> > Apache release policy [2] doesn't talk too much about whether release
> > candidates could include new features or new bug fixes. Could our mentor
> > give any advice on this?
> >
> > [1] https://semver.org/
> > [2] http://www.apache.org/legal/release-policy.html
> >
> > Wenli
> >
> >
> > On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com>
> wrote:
> >
> > > ------------------------------
> > > Su Shuang (100pah)
> > > ------------------------------
> > >
> > >
> > >
> > > ---------- Forwarded message ---------
> > > From: SHUANG SU <su...@gmail.com>
> > > Date: Mon, 26 Aug 2019 at 15:56
> > > Subject: [DISCUSS] Changelog issue
> > > To: <pr...@echarts.apache.org>
> > >
> > >
> > >
> > > Hi all,
> > >
> > > Shall we discuss a changelog issue:
> > >
> > > Suppose we have these versions:
> > > 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==> 4.2.1(formal
> > release)
> > >
> > > The changelog of 4.2.1, should be:
> > > A. The diff with 4.1.0
> > > (where the major part of the changelog of 4.2.1 will be
> duplicated
> > > with the changelog of 4.2.1-rc.1)
> > > B. The diff with 4.2.1-rc.1
> > > (where the changelog of 4.2.1 will contain only a little content,
> > > that is probably not appropriate for a "formal release")
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------
> > > Su Shuang (100pah)
> > > ------------------------------
> > >
> >
>
Re: [DISCUSS] Changelog issue
Posted by SHUANG SU <su...@gmail.com>.
> In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
not contain new features or fix bugs. They should only fix release-related
problems like license problems.
I agree with that.
> Even if there is an urgent issue, we should start a new hotfix version
rather than adding it in another release candidate.
I am afraid I don't agree with that.
For example, if we are in the procedure of release v4.3.0, the current
version that
is public testing is v4.3.0.rc-1, and a bug is found in this version.
If we fix this bug and immediately start a new hotfix version naming
v4.3.1, we will have no v4.3.0 any more.
If we publish v4.3.0 with the serious bug not fixed, and start a new hotfix
version naming v4.3.1,
the v4.3.0 probably harm users.
------------------------------
Su Shuang (100pah)
------------------------------
On Mon, 26 Aug 2019 at 16:17, Ovilia <ov...@gmail.com> wrote:
> I think it should be the changelog since the last formal release.
>
> In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
> not contain new features or fix bugs. They should only fix release-related
> problems like license problems.
> Even if there is an urgent issue, we should start a new hotfix version
> rather than adding it in another release candidate.
>
> Perhaps we should also discuss our version number policy in this thread.
> A popular method may be MAJOR.MINOR.PATCH [1].
> In this case, we may add the minor version in each regular monthly release,
> and use patch number to version hotfix versions.
>
> Apache release policy [2] doesn't talk too much about whether release
> candidates could include new features or new bug fixes. Could our mentor
> give any advice on this?
>
> [1] https://semver.org/
> [2] http://www.apache.org/legal/release-policy.html
>
> Wenli
>
>
> On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com> wrote:
>
> > ------------------------------
> > Su Shuang (100pah)
> > ------------------------------
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: SHUANG SU <su...@gmail.com>
> > Date: Mon, 26 Aug 2019 at 15:56
> > Subject: [DISCUSS] Changelog issue
> > To: <pr...@echarts.apache.org>
> >
> >
> >
> > Hi all,
> >
> > Shall we discuss a changelog issue:
> >
> > Suppose we have these versions:
> > 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==> 4.2.1(formal
> release)
> >
> > The changelog of 4.2.1, should be:
> > A. The diff with 4.1.0
> > (where the major part of the changelog of 4.2.1 will be duplicated
> > with the changelog of 4.2.1-rc.1)
> > B. The diff with 4.2.1-rc.1
> > (where the changelog of 4.2.1 will contain only a little content,
> > that is probably not appropriate for a "formal release")
> >
> >
> >
> >
> >
> > ------------------------------
> > Su Shuang (100pah)
> > ------------------------------
> >
>
Re: [DISCUSS] Changelog issue
Posted by Ovilia <ov...@gmail.com>.
I think it should be the changelog since the last formal release.
In my opinion, an updated release candidate (e.g. rc-2, rc-3 ...) should
not contain new features or fix bugs. They should only fix release-related
problems like license problems.
Even if there is an urgent issue, we should start a new hotfix version
rather than adding it in another release candidate.
Perhaps we should also discuss our version number policy in this thread.
A popular method may be MAJOR.MINOR.PATCH [1].
In this case, we may add the minor version in each regular monthly release,
and use patch number to version hotfix versions.
Apache release policy [2] doesn't talk too much about whether release
candidates could include new features or new bug fixes. Could our mentor
give any advice on this?
[1] https://semver.org/
[2] http://www.apache.org/legal/release-policy.html
Wenli
On Mon, Aug 26, 2019 at 4:04 PM SHUANG SU <su...@gmail.com> wrote:
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
>
> ---------- Forwarded message ---------
> From: SHUANG SU <su...@gmail.com>
> Date: Mon, 26 Aug 2019 at 15:56
> Subject: [DISCUSS] Changelog issue
> To: <pr...@echarts.apache.org>
>
>
>
> Hi all,
>
> Shall we discuss a changelog issue:
>
> Suppose we have these versions:
> 4.1.0(formal release) ==> 4.2.1-rc.1(pre-release) ==> 4.2.1(formal release)
>
> The changelog of 4.2.1, should be:
> A. The diff with 4.1.0
> (where the major part of the changelog of 4.2.1 will be duplicated
> with the changelog of 4.2.1-rc.1)
> B. The diff with 4.2.1-rc.1
> (where the changelog of 4.2.1 will contain only a little content,
> that is probably not appropriate for a "formal release")
>
>
>
>
>
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>