When VFS went from 1.0 to 2.0 the API was not compatible. This meant the package names had to change and the groupId/artifactId in the pom had to be different. If the new release is compatible with the prior release I would keep the naming conventions the same. Otherwise you run the risk of people mistakenly including both jars thinking they are different.
Ralph > On Dec 2, 2014, at 11:36 PM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
