The current tarball (*) staging process uses Nexus, which works well for Maven jars and is OK as a means of staging tarballs for voting.
However: once the vote succeeds, the tarballs need to be extracted and pushed to the dist/release repo. This is tricky and error-prone; it's possible to delete a file that's needed. One way round this is to drop the tarballs from Nexus before the vote and upload to create a separate staging area. But that's tedious as well, and the tarballs have to be picked out of the local repo and uploaded somewhere else. ---- After various experiments, I think the tarballs must be staged separately from the jars. This would avoid any need to update the Nexus staging area. The idea is to adjust the deploy phase so it creates the tarballs, sigs and hashes in their own directory - which is not uploaded to Nexus. A new plugin would be used to upload the directory to the dist/dev staging area, for example to https://dist.apache.org/repos/dist/dev/commons/commons-net-3.3-RC1[/binaries|/source] The RC voting would then take place as usual (with one extra URL for the tarballs). If the RC succeeds, Nexus can be promoted as usual, and the new plugin used to move the dist/dev files to dist/release. I think this would be a useful simplification of the process, and should eliminate all the tedious manual copying etc. Does this seem reasonable? == The new plugins that are required are just about ready; once they have been released we could make a start on updating the parent POM. (*) source and binary packages distributed via the ASF mirror system. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
