cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject 3.0.1 - next steps
Date Wed, 18 Aug 2010 07:33:13 GMT
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-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.


View raw message