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 <sushuang0...@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 <oviliazh...@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 <shenyi....@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 <oviliazh...@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 <sushuang0...@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 <oviliazh...@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 <sushuang0...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > ------------------------------ > > > > > > > Su Shuang (100pah) > > > > > > > ------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------- Forwarded message --------- > > > > > > > From: SHUANG SU <sushuang0...@gmail.com> > > > > > > > Date: Mon, 26 Aug 2019 at 15:56 > > > > > > > Subject: [DISCUSS] Changelog issue > > > > > > > To: <priv...@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-unsubscr...@echarts.apache.org For additional commands, e-mail: dev-h...@echarts.apache.org
