As well as moving to svnpubsub for Commons websites, infra require the use of svn for dist releases - i.e. the non-Maven releases.
I have set up the required top-level SVN folders [1][2], and asked infra to direct commit messages to commits@commons.a.o so we can keep track of them. The dev tree [1] is intended for release candidates. The release tree [2] must be used for releases. Checkins to the release tree automatically get synchronised to the main ASF mirrors (www.[eu|us].apache.org/dist). Once the commit mailing list has been set up, we can populate the release tree with our existing releases. We then ask infra to enable svnpubsub, and from then on all releases have to be made via the SVN repo, rather than uploading to minotaur. The release process then becomes: 1) upload RC to the dev tree 2) if vote fails, delete the RC and restart 3) if vote succeeds, rename the archives (sigs, hashes) from the dev tree to the release tree. [Maven releases will continue to be done via Nexus.] The process ideally needs to be automated in the same way that Maven deployment is automated. I'm hoping that it will be possible to adapt the Commons build plugin to create the necessary scripts to upload and then drop or publish the RC files. [The plugin is already able to create the download pages, so must be able to extract the names of all the release archives from the component Maven POM and associated files.] Note that using SVN means that it will no longer be necessary to login to minotaur - RCs can be directly imported to SVN. Using a rename to move the RC from dev tree to release tree means that it is easy to trace the release files back to the RC files which were used in the release vote. There are still a few details that need to be worked out, for example the naming convention for RCs and the directory structure for the dev staging area. It would be possible to use either a flat directory structure (binaries and source together) or use a mirror of the release directory structure. I suspect it will be easier to review RCs if a flat directory structure is used, so I suggest the following (using LANG as an example): dev/commons/lang/lang-1.2-RC2/ rather than splitting the files between the following: dev/commons/lang/lang-1.2-RC2/binaries dev/commons/lang/lang-1.2-RC2/source The release directory structure must match the existing directory structure otherwise the download page links won't work. The Maven build process creates all the archives in the same directory initially, so at some point in the process the source and binaries have to be divided anyway; seems to me it's easiest to do this on release. Hope this all makes sense! [1] https://dist.apache.org/repos/dist/dev/commons [2] https://dist.apache.org/repos/dist/release/commons --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
