Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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 : > 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 : > >> 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 >> 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 : >> > >> > > 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, >> 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 >> >
Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)
On Wed, May 23, 2018 at 6:16 AM, Greg Stein wrote: > On Mon, May 21, 2018 at 2:52 AM Justin Mclean > wrote: >>... Do people think it OK to include minified JS in a source release if: >> 1. It's ASF developed code and the full unminified source code is included >> as well. >> > Absolutely... Same here, as long as there's a documented way (automated ideally) of recreating the minified version, people can find out themselves that it's the correct version, if they want to check. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)
On Wed, May 23, 2018 at 12:16 AM Greg Stein wrote: > On Mon, May 21, 2018 at 2:52 AM Justin Mclean > wrote: > > > Hi, > > > > > 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. > > > > Thanks Ted I’ve not thought of it in that way before. I've seen several > > source releases that include minified javascript I'm just curious what > > people think about this. > > > > Do people think it OK to include minified JS in a source release if: > > 1. It's ASF developed code and the full unminified source code is > included > > as well. > > > > Absolutely. > > Also agree, yes. > Think "autoconf" ... the resulting "configure" file is as opaque as a > minified JS file or a binary. Nobody edits/modifies that shell script. And > we've been doing this for *years* ... it's natural and normal. > > I agree. It's only a problem if the project does not include the original source, like in https://issues.apache.org/jira/browse/THRIFT-4119 (an outstanding omission of source issue currently described as "intended behavior"). > The general rule is "don't place generated artifacts into source control", > but we nearly always include generated artifacts in our source releases. > > > > 2. The minified JS is 3rd party code, is identified by version (and thus > > can be checked via a comparison with the canonical minified version) > > > > I recommend using a CDN for these, when possible (eg. bootstrap and jquery) > as noted else-thread. That works well for the end-user, and avoids many of > these questions. > > Accumulo recently addressed a similar situation. We ended up bundling non-minimized, but made the webapp configurable, in case users want to switch to a non-bundled minimized version, a more up-to-date version (jQuery gets a lot of security updates), or one from their preferred CDN. I would strongly agree with Greg's recommendation to use a CDN by default... but if you need to bundle... making it user-configurable might be an option. There might be another good reason to avoid bundling minified versions, and this reason specifically applies to *minified* (obfuscated) source (rather than to all generated code): that is, it's not considered "free software" according to the Free Software Foundation ( http://www.gnu.org/philosophy/free-sw.html), nor are they considered "open source" according to the Open Source Initiative (http://opensource.org/osd). Of course, these definitions aren't necessarily ASF definitions... but they do tend to be respected definitions (this was first brought to my attention by the Fedora/RedHat community, which tends to be very strict about these things). > Cheers, > -g >
Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)
On Mon, May 21, 2018 at 2:52 AM Justin Mclean wrote: > Hi, > > > 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. > > Thanks Ted I’ve not thought of it in that way before. I've seen several > source releases that include minified javascript I'm just curious what > people think about this. > > Do people think it OK to include minified JS in a source release if: > 1. It's ASF developed code and the full unminified source code is included > as well. > Absolutely. Think "autoconf" ... the resulting "configure" file is as opaque as a minified JS file or a binary. Nobody edits/modifies that shell script. And we've been doing this for *years* ... it's natural and normal. The general rule is "don't place generated artifacts into source control", but we nearly always include generated artifacts in our source releases. > 2. The minified JS is 3rd party code, is identified by version (and thus > can be checked via a comparison with the canonical minified version) > I recommend using a CDN for these, when possible (eg. bootstrap and jquery) as noted else-thread. That works well for the end-user, and avoids many of these questions. Cheers, -g
Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)
On Mon, May 21, 2018 at 4:22 PM, Ted Dunning wrote: > On Mon, May 21, 2018, 21:12 Justin Mclean > wrote: > > > Hi, > > > > > Why does this need to be included at all? Why not just provide a > pointer > > to > > > the canonical minified version? > > > > Most common occurrence (off the top of my head) is a minified version of > > bootstrap for project site / documentations. So your view is that that > > shouldn’t be included in a source release? > > > > Sure. D3 and jQuery will wind up in the same boat. > > I would not go so far as to emphatically say not to include them, but I > don't see the real need to include them given that they are so easily > downloadable. A URL and a checksum keeps the distro clean. > Point to a CDN instead of copying into the distro? On the one hand, one can argue a CDN is bad if someone wants to read offline. On the other, I don't like being added to the security update chain if there is an issue in D3/jQuery/bootstrap etc. Hen
Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)
On Mon, May 21, 2018, 21:12 Justin Mclean wrote: > Hi, > > > Why does this need to be included at all? Why not just provide a pointer > to > > the canonical minified version? > > Most common occurrence (off the top of my head) is a minified version of > bootstrap for project site / documentations. So your view is that that > shouldn’t be included in a source release? > Sure. D3 and jQuery will wind up in the same boat. I would not go so far as to emphatically say not to include them, but I don't see the real need to include them given that they are so easily downloadable. A URL and a checksum keeps the distro clean. >
Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)
Hi, > Why does this need to be included at all? Why not just provide a pointer to > the canonical minified version? Most common occurrence (off the top of my head) is a minified version of bootstrap for project site / documentations. So your view is that that shouldn’t be included in a source release? Thanks, Justin
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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 : > 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 > 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 : > > > > > 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, > 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 : > > > > > > > > > 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 > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > As there is only one zip file, I guess it just the src
Re: Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)
On Mon, May 21, 2018 at 12:52 AM, Justin Mclean wrote: > Hi, > > > 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. > > Thanks Ted I’ve not thought of it in that way before. I've seen several > source releases that include minified javascript I'm just curious what > people think about this. > > Do people think it OK to include minified JS in a source release if: > 1. It's ASF developed code and the full unminified source code is included > as well. > I would much rather simply provide instructions for creating the minified version. > 2. The minified JS is 3rd party code, is identified by version (and thus > can be checked via a comparison with the canonical minified version) > Why does this need to be included at all? Why not just provide a pointer to the canonical minified version?
Minified Javascript in source releases (was Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3)
Hi, > 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. Thanks Ted I’ve not thought of it in that way before. I've seen several source releases that include minified javascript I'm just curious what people think about this. Do people think it OK to include minified JS in a source release if: 1. It's ASF developed code and the full unminified source code is included as well. 2. The minified JS is 3rd party code, is identified by version (and thus can be checked via a comparison with the canonical minified version) Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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 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 : > > > 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, 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 : > > > > > > > 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 > > 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
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
On Sun, May 20, 2018 at 10:07 PM, SHUANG SU 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" ... It's not purely about being able to check things, nor about how you define the word "compiled". You also need to be able to make changes. From http://www.apache.org/legal/release-policy.html#compiled-packages : "... All releases are in the form of the source materials needed to make changes to the software being released. ..." In the sense that the original source has been passed through a tool that mangled it into a form that can't be readily modified, it's not source, even if you don't want to call it "compiled". - Mike
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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 : > 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, 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 : > > > > > 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 > 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 > > > 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 > > > > >
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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, 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 : > > > 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 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 > > 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 "apac
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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 : > 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 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 > 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-incubating/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 vo
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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 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 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-incubating/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) > > -- > > >
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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 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-incubating/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) > -- >
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
John, (1) The included jar file of license check tool (Rat) is for developers' convenience. Basically, the infrastructure about building, checking and releasing of the ECharts is based on Node.js, thus it is not convenient for the developers and users to find and install Java-based tool (Rat) to check or add the file license. (Most of them do not have the Maven installed, or even some of them do not have the Java environment installed, and basically, it should not be necessary). So we include the jar directly for there convenience, and also provides a Node.js based license check tool included (build/addHeader.js) providing the same functionality. But I have no idea yet what update should be added to LICENSE or NOTICE for this checking tool. Could I have some detailed suggestion or example? (2) About wrapper The source file of the wrapper (build/rat/runrat.jar) is included in "build/rat/src/**". Providing a wrapper to run Rat is something helplessness. The Rat provides the feature of "list excluding regexp patterns in a file (say, ".rat-excludes")", but the patterns can only match the file names but not the file paths. Commonly, this kind of feature enables to match file paths, which is necessary. For example, I want to accurately exclude a file "test/lib/abcd.js", but do not want to exclude other files named "abcd.js", and this kind of files should be listed in the file ".rat-excludes" for maintenance consideration. I can not find a direct way to do it in Rat. So I have to make a wrapper to run Rat as a workaround to resolve the issue. ( Some details about why Rat does not support match file path: In the "org.apache.rat.walker.Walker#isIgnore" (v0.12), see "http://svn.apache.org/repos/asf/creadur/rat/tags/apache- rat-project-0.12-RC3/apache-rat-core/src/main/java/org/ apache/rat/walker/Walker.java", the "filter.accept(dir, name)" is called with the input of "dir" (file base dir) and "name" (file name without path). But in the implementation of the "org.apache.commons.io.filefilter.RegexFileFilter" and "org.apache.commons.io.filefilter.WildcardFileFilter" (v2.2), only "name" is used and "dir" is ignored, see "https://git1-us-west.apache.org/repos/asf?p=commons-io. git;a=blob;f=src/main/java/org/apache/commons/io/filefilter/RegexFileFilter. java;h=968b8c9df553392b01a58fc799920dfec764eb53;hb= 98f8e1a4334084c900bec1f62bdfe190dce8d5df" ) Shuang -- Su Shuang (100pah) -- 2018-05-17 20:40 GMT+08:00 John D. Ament : > Shuang, > > Apologies for my late reply. > > Only issue I see is the inclusion of compiled code in the source release. > It's generally expected to not have class files, jars in the source > release. We have good faith on what is included, but no way to confirm. > Also, since you now include RAT in the distribution, there's no NOTICE or > LICENSE updates required? (I haven't checked). > > Is it possible for you just to provide instructions on how to run rat in > the project, rather than creating a wrapper? > > John > > On 2018/05/17 11:42:22, SHUANG SU 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-incubating/build/rat/runrat.jar" | > less > > # (See help: `java -jar >
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
Shuang, Apologies for my late reply. Only issue I see is the inclusion of compiled code in the source release. It's generally expected to not have class files, jars in the source release. We have good faith on what is included, but no way to confirm. Also, since you now include RAT in the distribution, there's no NOTICE or LICENSE updates required? (I haven't checked). Is it possible for you just to provide instructions on how to run rat in the project, rather than creating a wrapper? John On 2018/05/17 11:42:22, SHUANG SU 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/67dffef28ecffd66689ac991ca027c0868d734629949d958e7b12dd3@%3Cdev.echarts.apache.org%3E > > Results thread: > https://lists.apache.org/thread.html/3a6e627a7e07d5de0856296d44bb408e17ee6795cc74ef190a7a5d23@%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-incubating/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) > -- > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
BTW: >From the Apache Echarts (incubating) 4.1.0.rc1 to 4.1.0.rc3, the license of source code files has been added, including the licenses of the third-party libs, and the Apache Rat has been executed against the project. -- Su Shuang (100pah) -- 2018-05-17 19:42 GMT+08:00 SHUANG SU : > > > 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-incubating/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) > -- > >
[VOTE] Release Apache ECharts (incubating) 4.1.0.rc3
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/67dffef28ecffd66689ac991ca027c0868d734629949d958e7b12dd3@%3Cdev.echarts.apache.org%3E Results thread: https://lists.apache.org/thread.html/3a6e627a7e07d5de0856296d44bb408e17ee6795cc74ef190a7a5d23@%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-incubating/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) --
