Apache does not officially release built artifacts. We only release source. So the release package should include all the source needed to build that release.
It is common practice for projects to also release built binaries (or their equivalent as is the case here). This is a convenience only, it is not the actual release though. The reason for this is that we encourage everyone to build from source so that they can verify that it is, to the best of our knowledge, free of any interference from third parties. When we distribute, for example, via NPM we cannot control what happens to the package after we release it. It is hosted outside of our servers and thus outside of our control. I hope that helps. Ross -----Original Message----- From: Tim Barham [mailto:[email protected]] Sent: Sunday, March 15, 2015 10:29 PM To: [email protected] Subject: RE: [VOTE] Ripple release 0.9.28 Some further question on this: > 3. Don't include the built files (the entire pkg folder) in the package for > Apache (but do include them in the package we upload to NPM, so people can > install Ripple from there without having to build). Since, as you say, > these are effectively the projects "binaries", would it matter that these > files on NPM don't have headers? Given that the source code is available on GIT (on Apache and github), is this package supposed to contain all the that source code (everything that is required to build Ripple, and test code), or just what is required to install and run Ripple? I notice Cordova packages only contain what is required to install and run Cordova - they don't include test code, for example, and some other stuff (but then for Cordova there's no real build process other than what occurs when npm installs the package). The Ripple package is currently built like the Cordova packages - using the folders and files defined in the files section of package.json (in other words - only what is required for the npm package). It doesn't include some folders which would be required to build Ripple (such as the thirdparty folder), nor the test folder. So for the purpose of the Apache release, should I build a package that includes all the Ripple source code (everything that is in git), and excludes the pkg folder (which is generated by building Ripple, and is not part of it source)? Thanks! Tim -----Original Message----- From: Tim Barham [mailto:[email protected]] Sent: Monday, March 16, 2015 3:13 PM To: [email protected] Subject: RE: [VOTE] Ripple release 0.9.28 Thanks again for putting the time into checking out the package, Christian. I have some feedback on these issues: > NOTICE -> 2012 :) Hah, yeah :). So... Should I just change that to 2015, or should it be "20xx-2015" where "20xx" would be I guess when Ripple moved to become an Apache project? > pkg/hosted/ripple.js appears to be empty. Is that correct? Hmmm, it looks ok to me. It's a fairly large file (all the Ripple's js concatenated together and minified), so can take a long time to load in some editors (and I've had it cause some editors to crash) :). > pkg/hosted do not have license headers. It looks like this would generated > code, which is uploaded to somewhere? Yeah, everything under "pkg" is the output of building Ripple. These files (js and css files) are concatenated from files in the project, and are actually built with headers. Ripple.js also includes the full text of the LICENSE file at the start, when it is built. However, they are all minified and the comments are stripped out. I'm not familiar with how Apache projects generally work in this regard, but some possibilities I can think of: 1. Don't minify it (minifying reduces the size from ~2.4MB to ~1.6MB). I believe this file is always loaded locally (is that correct, Brent - is Ripple itself every launched from a server other than localhost?), so perhaps the size isn't that much of an issue. And it would certainly make debugging easier :). 2. Minify it, but append the Apache license. However, this wouldn't be enough, as some of the contents come from third part sources with their own license headers. 3. Don't include the built files (the entire pkg folder) in the package for Apache (but do include them in the package we upload to NPM, so people can install Ripple from there without having to build). Since, as you say, these are effectively the projects "binaries", would it matter that these files on NPM don't have headers? I'm leaning towards the third option, as it seems the correct approach given Apache's focus on source code. > /assets/server/images/NOTICE: its in a folder where only the logo remains. Is > the location intended? A couple of thoughts: 1. That NOTICE doesn't seem to make sense, since the only image in that folder is Ripple specific. My understanding is that all images that couldn't be included under the Apache license were removed from Ripple - Brent do you know the details? 2. Brent do you know how the sever stuff is used? If I launch assets/server/index.html I get a bunch of stuff that seems to be out of date :). Thanks, Tim -----Original Message----- From: Christian Grobmeier [mailto:[email protected]] Sent: Friday, March 13, 2015 5:16 PM To: [email protected] Subject: Re: [VOTE] Ripple release 0.9.28 I found the following issues: NOTICE -> 2012 :) pkg/hosted/ripple.js appears to be empty. Is that correct? pkg/hosted do not have license headers. It looks like this would generated code, which is uploaded to somewhere? In Java-terms it would be similar to a binary artifact, which also do not have headers. This might come up as an issue. At Apache we are releasing source code first, everything else is just nice. The best and easiest thing would be to just add the header (automatically) to that files. Are there any options? /assets/server/images/NOTICE: its in a folder where only the logo remains. Is the location intended? I see a lot of images in /pkg/hosted/images, but no NOTICE there Maybe the included message should just go to the global NOTICE file? Thanks, i feel we are close :) Christian -- Christian Grobmeier http://www.grobmeier.de http://www.timeandbill.de On Tue, Mar 10, 2015, at 15:14, Tim Barham wrote: > Please review and vote on the release of Ripple 0.9.28. > > The package you are voting on is available for review at > http://bit.ly/1FZ8meZ. It was published from its corresponding git tag: > incubator-ripple: 0.9.28 (1d95fed542) > > Since this will be an official Apache release of Ripple (our first!), > we must be particularly careful that it complies with all Apache > guidelines for an incubator release. As such, before voting +1, please > refer to and verify compliance with the checklist at > http://incubator.apache.org/guides/releasemanagement.html#check-list. > > If anyone has concerns that we don't meet any of these requirements, > please don't hesitate to raise them here so we can discuss and make > changes if necessary. > > If you do give a +1 vote, please include what steps you took in order > to be confident in the release. > > Please also note from Ross's recent email: > > > What we need is three +1 "binding" votes, in reality that means > > three IPMC members. Once a project graduates it means three project > > management committee members. However, as a mentor (therefore having > > a binding vote) I look to the project participants to indicate their > > preference and (assuming no blocking issues on an IP check) I'll > > always vote in support of the communities non- binding votes. > > So please, even though your vote may not be binding, take some time to > review the release and vote! > > Upon a successful vote, we will arrange for the archive to be uploaded > to dist/incubator/ and publish it to NPM. > > Thanks, and looking forward to our first official Ripple release! > > Tim
