Here is the relevant policy on releases (from http://www.apache.org/dev/release.html#what):
<quote> The Apache Software Foundation produces open source software. All releases are in the form of the source materials needed to make changes to the software being released. In some cases, binary/bytecode packages are also produced as a convenience to users that might not have the appropriate tools to build a compiled version of the source. In all such cases, the binary/bytecode package must have the same version number as the source release and may only add binary/bytecode files that are the result of compiling that version of the source code release. </quote> So, AFAIK, the only requirement for the binary file(s) is that the version matches. Of course, we can do as much as we want to verify that the binary files correspond to the sources... ~Roger -----Original Message----- From: Chris Bartlett [mailto:cbartlet...@gmail.com] Sent: Wednesday, June 05, 2013 2:28 PM To: Pivot Dev Subject: Re: [VOTE] Release Pivot 2.0.3 - Round 3 Roger, Your reversed method was to be my final resort but I didn't think it would really be acceptable as it is a bit of a hack. I certainly wasn't aware of the source versus binary distinction. Do you have a link handy for that? If not I will have a trawl around later myself. I was focusing on verifying that the supplied jars came from the correct source commit because all of my other testing had been fine. That was the last piece of the puzzle, but the one that I ran out of time on. Chris On 5 June 2013 22:17, Roger L. Whitcomb <roger.whitc...@actian.com> wrote: > I did the compare in reverse: unzip the release archives and compare > to SVN checkout (ignoring line-ending diffs). I very much doubt we > can compare binary .jar files exactly because of timestamp differences > regardless of line endings, though.... > > If it helps, the Apache convention is that what we release is SOURCE, > and the binary distributions are for convenience. So, the standard > for comparison on the .class/.jar files and other binary artifacts > does not have to be as stringent (IMO). Which is partly why I opted > to check that the source files in the release artifacts compare (as > exactly as > possible) to what is in SVN, and then to compare the file lists of the > .jar files with what I built from the source and do some basic sanity > checks using the binary .jar files with my application. > > Don't know if that will help with getting confidence from your tests > .... > > Noted, though, that the release build process is not very repeatable, > and I hope to address this in the future. > > ~Roger > > -----Original Message----- > From: Chris Bartlett [mailto:cbartlet...@gmail.com] > Sent: Wednesday, June 05, 2013 2:04 PM > To: Pivot Dev > Subject: Re: [VOTE] Release Pivot 2.0.3 - Round 3 > > On 5 June 2013 11:15, Sandro Martini <sandro.mart...@gmail.com> wrote: > > > > I think Sandro created the release on Linux, so likely the line > > > endings were \n and not \r\n as they would be in Windows. Also > > > the .jar files won't be exactly the same due to timestamps, and > > > probably > > > > subtle JDK differences (such as exact minor release number, etc.). > > > I used WinMerge on Windows with settings to ignore line-ending > > > diffs > > > > and "diff -r" on OSX to do my comparisons, which seems to verify > > > that the line endings in > > the sources files are \n only. > > Yes, out Release are always generated from Linux machines (or Mac > > OSX by Todd, many time ago), related scripts are Unix shell scripts > > since the beginning ... I'd like to update them to something more > > portable (for example Gradle ...) but didn't have enough time up to > > now, and I'm not sure it worth the effort. > > > > The problem with the current build process is that it is not easy to > recreate the release artifacts from source in a platform independent > way (unless I am missing something obvious). Ideally it should be > possible to checkout the correct tag/commit and run the relevant Ant > command to generate identical release artifacts regardless of the OS, > JDK version, locale etc. A binary comparison would confirm that the > proposed release artifacts came from the correct source code with no > modifications along the way. > > I'm not sure how to proceed with this vote without setting up an > equivalent build environment to perform that kind of test. It might > be something as simple as tweaking an existing SVN or git installation > to force unix line endings on checkout or may involve a linux build VM. > Due to other commitments, I doubt I would even be able to attempt any > of that until the weekend. > > I looked into the Ant FixCRLF task ( > http://ant.apache.org/manual/Tasks/fixcrlf.html) which might be able > to help sometime in the future but couldn't quickly get a working > configuration to process the source to match the proposed release > source. > There seemed to be too many variations in line endings, encodings & > EOFs to quickly tweak. > > > Roger - Yes, I had figured as much. I couldn't work out how to get > BeyondCompare to ignore line endings in its folder search mode but it > is useful to know about WinMerge. I think the compiler flags being > set to target 1.6 will ensure that classes are the same regardless of > the JDK version. >
