Hello, I think the Problem is the tag the m-release-p uses to puts into the SCM URL for the released POM. I will try if this can be a non-existing Tag/Branch (however I do not agree that this is a good thing). I actually like the procedure in your log4j2 description where you would rename the failed tries to -rcN tags.
However, for a first RC where it is expected to not be final (including a RC qualifier in the POM) I would release with an -rc1 tag. (should we use the new format if the 2.0 tag commons-vfs2-2.1-rc1 or go back to VFS2.1-rc1? Gruss Bernd -- http://bernd.eckenfels.net ----- Ursprüngliche Nachricht ----- Von: "Ralph Goers" <ralph.go...@dslextreme.com> Gesendet: 03.12.2014 06:52 An: "Commons Developers List" <dev@commons.apache.org> Betreff: Re: [VFS] Release Preparations 2.1 (again) > > > Unfortunately, I don’t believe I > > documented the release process but it should be similar to > > http://wiki.apache.org/logging/Log4j2ReleaseGuide > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide> > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I based > > the Log4j build and release process after VFS. > > > Before we do this, a couple of questions: > > - how hard is it to delete tags from SVN and who can do that? > > You should not delete tags from SVN. If you can commit, you can manage tags > and branches AFAIK. IMO, the process should be that we VOTE on an RC tag, if > the vote passes the RC tag is copied to a release tag. If it fails, you try > again with a new RC tag. The tags live in SVN as a record of what we VOTEd on. > I recall that at the time of the 2.0 release the release plugin used the same version as the artifact for tagging, but I could be wrong. I seem to recall that now the tag does not have to match, so what Gary is suggesting should be doable. Ralph
