incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [repo] /www/
Date Mon, 09 Apr 2007 02:09:23 GMT
On Monday 09 April 2007 08:12, Marc Prud'hommeaux wrote:

> I think that will generally work, but there is the issue of the
> "maven-metadata.xml" file in the parent directory (e.g., http://
> openjpa-project/maven-metadata.xml) that lists all of the releases.
> If you release to a different location and then manually move over
> the release subdirectories, the parent maven-metadata.xml won't
> automatically be updated. You could manually add the line to those
> files, but them the md5 and sha1 checksums would be wrong.

That is a correct observation.

ASF releases are all about source code, the binary artifacts are not really 
part of the problem domain.

I have never managed to figure out how people expect the workflow to be, but 
in my mind it is a matter of "Release Candidate" production prior to 
a "Release".
In practical terms; the release candidate sources are "tagged" with the "rc" 
marker in the versions, and copied into a subversion directory for the 
purpose. The release candidate is cut and uploaded for review. And if not 
pass, then fix in trunk and repeat with a new "rc". Once the "rc" is approved 
for release, redo the tagging of the "rc" sources into a "released" directory 
and without the "rc" marker. And cut the release from there.

Now, this assumes that for a given source repository, there is an automated 
process to cut the release, including checksumming, signing, uploading. It 
also requires that no changes are made in the "rc" and "released" 
directories, which I guess SVN ACL can take care of.

Maven doesn't support this workflow, but if the "rc" and "released" are tagged 
into the same SVN directory, then it is close.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message