On 5 June 2017 at 12:06, Benedikt Ritter <brit...@apache.org> wrote: > Hello Rob, > >> Am 28.05.2017 um 03:01 schrieb Rob Tompkins <chtom...@gmail.com>: >> >> Hello all, >> >> Benedikt and I were chatting last week about how the .tar and .zip >> distributions get uploaded to nexus during "mvn deploy” and how annoying >> that side effect of the deployment happens to be. Coincidentally, I just ran >> across a note that Mladen Turk added at the end of the commons-daemon >> release guide: >> >> https://github.com/apache/commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43 >> >> <https://github.com/apache/commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43> >> >> I’m thinking: (1) interesting note, knowing that the problem still exists, >> and (2) I wonder if there would be community appetite for an attempt at >> adding better automation to the release process. I’m betting that with a >> little effort we probably could improve the release experience at least a >> little. > > Nice catch, however I alway run clean when deploying, since I don’t want > stale build artifacts to be deployed (this happened to me once).
Unfortunately that may not be sufficient, as it won't remove spurious source files. It's best to checkout the tag in a clean directory and build from there. IMO that is what the release plugin should do, however instead it updates the trunk version and builds from the 'unclean' workspace. If the RC fails, then trunk has to be backdated. Meanwhile any CI builds will have picked up the new SNAPSHOT version. The release plugin should assume that the RC may fail, and not update trunk until the release process succeeds. > I’m planning to ask the maven user list on how we can improve our deployment > process. They are unlikely to accept that the release plugin has limitations ... > Regards, > Benedikt > >> >> Cheers, >> -Rob > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org