Thanks all for the comments and discussions! The voting for the release of Apache ECharts 4.1.0 (release candidate 3) is closed. And a new voting for the release of Apache ECharts 4.1.0 (release candidate 4) has been initialized in another thread: https://lists.apache.org/thread.html/4a551cd183a7ec74c2f5629b8c2c128f82cff6d044d524fcc4d2a175@%3Cgeneral.incubator.apache.org%3E
Thanks. ------------------------------ Su Shuang (100pah) ------------------------------ 2018-05-22 0:04 GMT+08:00 SHUANG SU <sushuang0...@gmail.com>: > Mike and Ted, thanks a lot for your detailed explanation! > > I've been gradually understanding the way that the community thinks > about the "release". And I will fix the artifact soon. > > Thanks, > Shuang > > > > ------------------------------ > Su Shuang (100pah) > ------------------------------ > > > 2018-05-21 14:01 GMT+08:00 Ted Dunning <ted.dunn...@gmail.com>: > >> The general meaning of source code is that it is the artifact that people >> will edit and which they can inspect by normal textual or graphical means >> to ensure that there are no surprises. >> >> Javascript code that is minified or combined in any major way is much more >> like binary code in that respect. It is true that somebody *could* inspect >> the correlation, but it is not true that this inspection is either >> normally >> done or easily done. >> >> As a rule of thumb, you should not include any artifacts that require more >> work to verify than you expect nearly all release reviewers to do for >> *every* release candidate. Usually that means that there are no derived >> artifacts at all in a source release since that is the only case which is >> easy for reviewers. >> >> >> >> On Sun, May 20, 2018 at 10:07 PM, SHUANG SU <sushuang0...@gmail.com> >> wrote: >> >> > Thanks, Justin, >> > >> > I think I should remove the jar about rat from the artifact, and then >> there >> > is no binary code anymore. >> > >> > But I am puzzled about the definition of the term "compiled code". >> > Generally, the JavaScript code does not need to be compiled to binary. >> > The code in "dist/**" is also JavaScript code, which is combined to some >> > single files >> > and some of them are minified. And the ".map" file is provided for >> mapping >> > each term >> > of the combined code to the original code in src/**. Without or without >> the >> > ".map", >> > the combined code can be checked. >> > I think this kind of combined code is not "compiled code", but I don't >> know >> > the formal definition >> > about this case. >> > >> > Thanks, >> > Shuang >> > >> > >> > >> > >> > ------------------------------ >> > Su Shuang (100pah) >> > ------------------------------ >> > >> > >> > 2018-05-21 5:31 GMT+08:00 Justin Mclean <justinmcl...@gmail.com>: >> > >> > > Hi, >> > > >> > > Releases at the ASF must not contain compiled code. You can if you >> want >> > > also produce a conviance binary for users at the same time but the >> source >> > > release needs to contain no compiled code otherwise it's not open >> source. >> > > >> > > Thanks, >> > > Justin >> > > >> > > On Mon., 21 May 2018, 7:10 am SHUANG SU, <sushuang0...@gmail.com> >> wrote: >> > > >> > > > Thanks, Willem. >> > > > >> > > > But I will explain the reason that provides an all-in-one artifact. >> > > > >> > > > I understand that one of the reasons for separating src and binary >> > files >> > > > is that in some project the compilation is depending on the target >> > > runtime >> > > > environment and thus the products cannot be enumerated completely. >> > > > The other reason might be that the binary files are different to be >> > > > checked. >> > > > (Am I correct? or miss something notable?) >> > > > >> > > > But in this kind of JavaScript program, the built products is >> > environment >> > > > independent and can be enumerated completely. >> > > > >> > > > And the build products of the JavaScript project is text-based, >> which >> > can >> > > > be >> > > > checked basically. >> > > > >> > > > Moreover, there are too many approaches to require and use a >> JavaScript >> > > > project. >> > > > First of all, a user project may be a browser project or run on >> > > > a server (Node.js) or both. >> > > > Both in those runtime environments, the user project may need to >> > > required a >> > > > pre-combined >> > > > built file via AMD or CommonJS module loader or global variable or >> some >> > > > bundle tools like >> > > > Webpack and rollup.js (provided in dist/**). >> > > > Or the user project may intent to require files separately on demand >> > via >> > > > CommonJS >> > > > or some bundle tools like Webpack and rollup.js (provided in >> lib/**). >> > > > Or the user project may intent to require files via ES module loader >> > > > (provided in src/**). >> > > > During the development of user projects, probably more than one >> > > approaches >> > > > are needed. >> > > > >> > > > So we both provide those files all-in-one in the artifacts for the >> > > > convenience of the users. >> > > > And this way follows the convention of most of the JavaSript libs, >> and >> > it >> > > > works well for years in >> > > > the ECharts community. >> > > > >> > > > >> > > > Truly, >> > > > Su Shuang >> > > > >> > > > >> > > > >> > > > ------------------------------ >> > > > Su Shuang (100pah) >> > > > ------------------------------ >> > > > >> > > > >> > > > 2018-05-21 0:25 GMT+08:00 Kevin A. McGrail <kmcgr...@apache.org>: >> > > > >> > > > > If the release candidate isn't correct for the artifacts you need >> to >> > > roll >> > > > > an rc4 which might be two files not one and send that for a vote. >> > > > > >> > > > > On Sat, May 19, 2018, 22:34 Willem Jiang <willem.ji...@gmail.com> >> > > wrote: >> > > > > >> > > > > > Hi, >> > > > > > >> > > > > > As there is only one zip file, I guess it just the src >> > distribution. >> > > > > > But after went through the file, I found lot of echart js files >> in >> > > the >> > > > > dist >> > > > > > directory and the rat jar. >> > > > > > >> > > > > > So I'm confused what's the purpose of apache-echarts-4.1.0.rc3- >> > > > > > incubating.zip >> > > > > > >> > > > > > Normally we distribute the src and binary files separately. >> > > > > > >> > > > > > >> > > > > > >> > > > > > Willem Jiang >> > > > > > >> > > > > > Blog: http://willemjiang.blogspot.com (English) >> > > > > > http://jnn.iteye.com (Chinese) >> > > > > > Twitter: willemjiang >> > > > > > Weibo: 姜宁willem >> > > > > > >> > > > > > On Thu, May 17, 2018 at 7:42 PM, SHUANG SU < >> sushuang0...@gmail.com >> > > >> > > > > wrote: >> > > > > > >> > > > > > > I am pleased to be calling this vote for the release of Apache >> > > > ECharts >> > > > > > > 4.1.0.rc3. >> > > > > > > >> > > > > > > Apache ECharts community has voted and approved the release. >> > > > > > > >> > > > > > > Vote thread: >> > > > > > > https://lists.apache.org/thread.html/ >> > > 67dffef28ecffd66689ac991ca027c >> > > > > > > 0868d734629949d958e7b12dd3@%3Cdev.echarts.apache.org%3E >> > > > > > > >> > > > > > > Results thread: >> > > > > > > https://lists.apache.org/thread.html/ >> > > 3a6e627a7e07d5de0856296d44bb40 >> > > > > > > 8e17ee6795cc74ef190a7a5d23@%3Cdev.echarts.apache.org%3E >> > > > > > > >> > > > > > > The release candidate to be voted over is available at: >> > > > > > > https://dist.apache.org/repos/dist/dev/incubator/echarts/4. >> > > 1.0.rc3/ >> > > > > > > >> > > > > > > The release candidate is signed with a GPG key available at: >> > > > > > > https://dist.apache.org/repos/dist/dev/incubator/echarts/KEYS >> > > > > > > >> > > > > > > A tagged git repository is available for review at: >> > > > > > > https://github.com/apache/incubator-echarts/releases/ >> > tag/4.1.0.rc3 >> > > > > > > >> > > > > > > The Git commit for this release is: >> > > > > > > https://gitbox.apache.org/repos/asf?p=incubator-echarts. >> > > > > > > git;a=commit;h=f98eb21 >> > > > > > > >> > > > > > > The Release Note is available in: >> > > > > > > https://dist.apache.org/repos/dist/dev/incubator/echarts/4. >> > > > > > > 1.0.rc3/RELEASE_NOTE.txt >> > > > > > > >> > > > > > > Some shell commands for validating the release: >> > > > > > > >> > > > > > > ```shell >> > > > > > > # Download the release: >> > > > > > > curl >> > > > > > > https://dist.apache.org/repos/dist/dev/incubator/echarts/4. >> > > > > > > 1.0.rc3/apache-echarts-4.1.0.rc3-incubating.zip >> > > > > > > -o apache-echarts-4.1.0.rc3-incubating.zip >> > > > > > > unzip apache-echarts-4.1.0.rc3-incubating.zip -d >> > > > > > > apache-echarts-4.1.0.rc3-incubating > /dev/null >> > > > > > > >> > > > > > > # Rebuild the project: >> > > > > > > cd "apache-echarts-4.1.0.rc3-incubating" && npm install && >> cd .. >> > > > > > > node "apache-echarts-4.1.0.rc3-incubating/build/build.js" >> > > --release >> > > > > > > # (See help: `node "apache-echarts-4.1.0.rc3- >> > > > > incubating/build/build.js" >> > > > > > > --help`) >> > > > > > > >> > > > > > > # Run Apache Rat: >> > > > > > > java -jar "apache-echarts-4.1.0.rc3-incu >> bating/build/rat/runrat. >> > > jar" >> > > > | >> > > > > > > less >> > > > > > > # (See help: `java -jar >> > > > > > > "apache-echarts-4.1.0.rc3-incubating/build/rat/runrat.jar" >> > > --help`) >> > > > > > > ``` >> > > > > > > >> > > > > > > >> > > > > > > Please vote on releasing this package as: >> > > > > > > Apache ECharts 4.1.0.rc3 >> > > > > > > >> > > > > > > This vote will be open until "2018-05-20T12:33:24.955Z". >> > > > > > > >> > > > > > > [ ] +1 Release this package >> > > > > > > [ ] 0 I don't feel strongly about it, but don't object >> > > > > > > [ ] -1 Do not release this package because... >> > > > > > > >> > > > > > > Anyone can participate in testing and voting, not just >> > committers, >> > > > > please >> > > > > > > feel free to try out the release candidate and provide your >> > votes. >> > > > > > > >> > > > > > > >> > > > > > > ------------------------------ >> > > > > > > Su Shuang (100pah) >> > > > > > > ------------------------------ >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
