Hello, I checked the release-plugin documentation and I cannot find a way to specify different tags for the usage inside the prepared POM and the Tag which should be used for actually tagging.
I also think this is pretty uncommon, and I would go with using the final release version tag (commons-vfs2-project-2.1 or commons-vfs-2.1 or vfs-2.1 depending on the outcome of the discusssion). As mentioned before, I am fine with having at least one non-final RC produced using a RC tag and the commons.rc.version=RC1 specified. But as soon as we think we can produce a result I woul run the release plugin with the final tag. BTW: -P apache-release does not work with VFS as it fails the source:single execution (missing assembly descriptor which is in dist/ for VFS). It seems to work with -Prelease, do we want to use this? Gruss Bernd Am Tue, 2 Dec 2014 22:50:03 -0700 schrieb Ralph Goers <ralph.go...@dslextreme.com>: > > > > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
