Taking a fresh look at all the points made in this discussion, my conclusions are the following:
1. Lack of mention of VPP in the NOTICE file is an omission that we must fix.
2. Other than (1), Cayenne has been making valid and compliant releases all along, as we did include the source code that can be built into Cayenne runtime that matches the binaries that we distribute. The issue of build file is secondary. It is an issue of quality, not compliance if you will. Source is now distributed as a single module, and writing build.xml to make a jar out of it is *not* hard (or alternatively importing it in Eclipse, adding needed deps based on errors in import statements, and exporting it as a jar is trivial). But in any event, this is still a "quality" argument.
Addressing Mike's earlier comment:
> if you want to say that we're meeting the source build
> requirement, consider this. It would mean that everyone voting +1 on a
> release has somehow thrown a home-grown build-system on top of the
> source release and successfully built it. Because that's the only
> way an evaluator can be sure that the release has met the condition
> and the release manager hasn't accidentally left out some required
> piece of source.
Actually being able to build the source doesn't prove that release manager haven't missed some files. The source can still build in such case (e.g. consider an absurd case of RM throwing out Cayenne source entirely, replacing it with one HelloWorld class). What exactly is proven by building the source? It is just one of the parts of a release "smoke test" [1]. I guess you could check out the tag and checksum individual source files and then checksum the same files from release sources. This will guarantee no rogue or missing contents. But this doesn't require a build.
3. Next steps. I suggest to restart 3.0.1 vote by fixing (1), and later discuss whether we want to provide a separate source artifact made by tar'ing up the source tree sans test cases and a few special modules. I think this can be easily done with assembly plugin. So in addition to cayenne.tar.gz, cayenne-win.zip, cayenne-osx.dmg, we'd also distribute cayenne-src.tar.gz (or we put it in each one of the 3 platform files). Once we agree on a format, we can open a Jira and add it in the following releases. My preference would be to leave 3.0.* release structure untouched, and put it in 3.1.
Andrus
[1] http://en.wikipedia.org/wiki/Smoke_testing
This archive was generated by hypermail 2.0.0 : Wed Aug 18 2010 - 07:34:02 UTC