[DISCUSS] do additional artifacts need to be removed as part of the release process.

[Rick McGuire <ri...@gmail.com>]

This is an issue that came up with the vote on 1.0 Yoko release.  The 
new release process detailed at

http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+release+process

generates a bunch of extra artifacts that are .md5 and sha1 signatures 
for the .asc files. So, for every jar file, you will get a .asc file, 
plus additional asc.md5 and asc.sha1 files. 

In our old release process, one of the steps was to erase all of the 
*.asc.* files before staging the release for a vote.  Now that this is 
done automatically by using the plugins, these extra artifacts get 
included, and even get staged to the repos.  For example, see the 
artifacts that got published for the last javamail release, which was 
the most recent release to use this process:

http://repo1.maven.org/maven2/org/apache/geronimo/javamail/geronimo-javamail_1.4_provider/1.4/

Should our release process include the step to delete these additional 
files?  Or should this be something that should/could be fixed in the 
plugin so that these extraneous files don't get included accidentally?

Rick

Re: [DISCUSS] do additional artifacts need to be removed as part of the release process.

[Jason Dillon <ja...@planet57.com>]

I'm not sure we want to do that... as we move closer to using the  
maven-artifact library to handle the repository bits, these files will  
be critical to include... to avoid misleading warnings.

--jason


On May 12, 2008, at 7:09 PM, Rick McGuire wrote:

> This is an issue that came up with the vote on 1.0 Yoko release.   
> The new release process detailed at
>
> http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+release+process
>
> generates a bunch of extra artifacts that are .md5 and sha1  
> signatures for the .asc files. So, for every jar file, you will get  
> a .asc file, plus additional asc.md5 and asc.sha1 files.
> In our old release process, one of the steps was to erase all of the  
> *.asc.* files before staging the release for a vote.  Now that this  
> is done automatically by using the plugins, these extra artifacts  
> get included, and even get staged to the repos.  For example, see  
> the artifacts that got published for the last javamail release,  
> which was the most recent release to use this process:
>
> http://repo1.maven.org/maven2/org/apache/geronimo/javamail/geronimo-javamail_1.4_provider/1.4/
>
> Should our release process include the step to delete these  
> additional files?  Or should this be something that should/could be  
> fixed in the plugin so that these extraneous files don't get  
> included accidentally?
>
> Rick

Re: [DISCUSS] do additional artifacts need to be removed as part of the release process.

[David Jencks <da...@yahoo.com>]

On May 12, 2008, at 6:31 AM, Joe Bohn wrote:

> Rick McGuire wrote:
>> This is an issue that came up with the vote on 1.0 Yoko release.   
>> The new release process detailed at
>> http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+release+process 
>>  generates a bunch of extra artifacts that are .md5 and sha1  
>> signatures for the .asc files. So, for every jar file, you will get  
>> a .asc file, plus additional asc.md5 and asc.sha1 files.
>> In our old release process, one of the steps was to erase all of  
>> the *.asc.* files before staging the release for a vote.  Now that  
>> this is done automatically by using the plugins, these extra  
>> artifacts get included, and even get staged to the repos.  For  
>> example, see the artifacts that got published for the last javamail  
>> release, which was the most recent release to use this process:
>> http://repo1.maven.org/maven2/org/apache/geronimo/javamail/geronimo-javamail_1.4_provider/1.4/ 
>>  Should our release process include the step to delete these  
>> additional files?  Or should this be something that should/could be  
>> fixed in the plugin so that these extraneous files don't get  
>> included accidentally?
>
>
> I had the same question when I released javamail.  After some  
> thought I decided that the extra files didn't hurt anything and  
> provide some measure of additional security in that you could (and  
> perhaps should) verify that the asc files themselves haven't been  
> corrupted.

I didn't understand why the original release instructions had the  
"delete the required signature files" step.  These files are required  
as part of an apache release and for uploading to a maven repo.  They  
should be checked as part of the release vote.  Don't remove them.

thanks
david jencks

>
>
> Joe

Re: [DISCUSS] do additional artifacts need to be removed as part of the release process.

[Joe Bohn <jo...@earthlink.net>]

Rick McGuire wrote:
> This is an issue that came up with the vote on 1.0 Yoko release.  The 
> new release process detailed at
> 
> http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+release+process 
> 
> 
> generates a bunch of extra artifacts that are .md5 and sha1 signatures 
> for the .asc files. So, for every jar file, you will get a .asc file, 
> plus additional asc.md5 and asc.sha1 files.
> In our old release process, one of the steps was to erase all of the 
> *.asc.* files before staging the release for a vote.  Now that this is 
> done automatically by using the plugins, these extra artifacts get 
> included, and even get staged to the repos.  For example, see the 
> artifacts that got published for the last javamail release, which was 
> the most recent release to use this process:
> 
> http://repo1.maven.org/maven2/org/apache/geronimo/javamail/geronimo-javamail_1.4_provider/1.4/ 
> 
> 
> Should our release process include the step to delete these additional 
> files?  Or should this be something that should/could be fixed in the 
> plugin so that these extraneous files don't get included accidentally?


I had the same question when I released javamail.  After some thought I 
decided that the extra files didn't hurt anything and provide some 
measure of additional security in that you could (and perhaps should) 
verify that the asc files themselves haven't been corrupted.

Joe