David Crossley wrote:
Sylvain Wallez wrote:
Please cast your votes:
[+1] do not keep sources
and use a full timestamp (as UTC time) in the jar filename
so that people can get the sources from the relevant
external CVS, e.g. foobar-20040628T0824.jar
Considering that everybody has strong arguments either for or against source inclusion, it seems we'll never be able to reach a consensus on this source preservation problem by including *some* of the sources in our CVS repo, either as part of the jars, either as separate zip files.
What is annoying me is that some people don't seem to have understood the value of this, which is to be able to easily track bugs into Cocoon in the transient state that separates official releases. Anyway...
I therefore withdraw the vote and consider David's proposal above a good mid-term solution that better helps to find the sources than a simple date timestamp.
However, we have to clearly define how this timestamp should be produced: *it cannot be the build time*, as the source repository may have changed between the checkout and the build.
So having this minute-precise timestamp means that:
- your computer is synchronized to an NTP server on the Internet,
- when checking out the CVS, you use "cvs update; date -u +%Y%m%dT%H%M" (what's the non-cygwin windoze equivalent?) to have the precise _checkout_ time in UTC.
- you make no modification on the source files after this update.
If you're a committer on the 3rd party library, the "cvs update; date" should be done again after any commit to take into account any other changes that other people may have made since your last update.
Does this sound better? Can we reach a consensus here?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
