commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <>
Subject AW: [VFS] Release Preparations 2.1 (again)
Date Wed, 03 Dec 2014 06:36:26 GMT

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?



----- Ursprüngliche Nachricht -----
Von: "Ralph Goers" <>
Gesendet: ‎03.‎12.‎2014 06:52
An: "Commons Developers List" <>
Betreff: Re: [VFS] Release Preparations 2.1 (again)

> > Unfortunately, I don’t believe I
> > documented the release process but it should be similar to
> > <>
> > < <>>,
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message