You're voting on a set of sources, and the state of them, more than the specific binary built on a specific platform. You're not really voting on the arbitrary binary that manifests itself as a result of those sources and build. Although it's possible to build from the same sources and get a (meaningfully) different binary, the chances of that are slim to none provided the developer is using the same box/dir/tools and the project is configured correctly. This can be handled by convention and discipline.
RC releases should be done as full blown releases with no extra flags, tagged and versioned throughout as what they are. Once an RC is accepted, simply adjust the version and release from the commit after the one the last RC came from (with a diff that is purely pom version field change). This is in Git terms. You're talking in SVN terms. These are impl details of the same approach. There are many ways to skin this cat acceptably. The main criteria (in my mind) is that no two binaries are built with the same version number. Rebuilding from the new tag (or just new commit in Git) can be handled by staging that one binary, and simply skipping it if the dev screwed something up. You could also just skip the RC stuff, which is pretty normal in typical maven-built stuff anyway, and never publish bad bins to central resulting in 1.1 1.7 1.24 2.0 in central. Even the matching binaries could be OK if there is a procedure to manually publish the hashes of the artifacts in question in the email announcement such that the intent of the developer can be checked against the reality down stream. Something like "I've released 0.1 of XYZ, with jar of hash abcdef123 and pom of hash 123456fedcba". with those hashes differing on the second try (if required). As stated, though, typically not many, if any, tries are required, as plenty of snapshots have been tried, and lots of testing is done on the sources intended to be released. Fred. On Wed, May 29, 2013 at 2:53 PM, Stephen Connolly < [email protected]> wrote: > Actually clarified that the release plugin is being used but the tag is > being forced to a different name and then moved post successful release, > e.g. > > mvn release:prepate release:perform -DreleaseVersion=3.1.0 -Dtag=3.1.0-RC1 > > Now there is an issue with that in that the pom will contain the wrong tag > in the scm section... > > $ svn log --limit 5 -v > https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.5 > ------------------------------------------------------------------------ > r1456364 | bodewig | 2013-03-14 08:43:27 +0000 (Thu, 14 Mar 2013) | 1 line > Changed paths: > A /commons/proper/compress/tags/COMPRESS-1.5 (from > /commons/proper/compress/tags/COMPRESS-1.5_RC1:1456363) > > Vote has passed, 1.5 is released > ------------------------------------------------------------------------ > r1455005 | bodewig | 2013-03-11 06:10:51 +0000 (Mon, 11 Mar 2013) | 1 line > Changed paths: > A /commons/proper/compress/tags/COMPRESS-1.5_RC1 (from > /commons/proper/compress/trunk:1455004) > M /commons/proper/compress/tags/COMPRESS-1.5_RC1/pom.xml > > Tagging first RC for Compress 1.5 > ------------------------------------------------------------------------ > > So they are not using the release plugin then... perhaps a pseudo-tag > option is needed for the release plugin then... > > On 29 May 2013 13:40, Barrie Treloar <[email protected]> wrote: > > > On 29 May 2013 20:53, Stephen Connolly <[email protected]> > > wrote: > > > The issue with that is when using the Maven Release Plugin, you will > not > > be > > ... > > > > Can't we fix the tooling then? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
