commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [VFS] Release Preparations 2.1 (again)
Date Wed, 03 Dec 2014 15:01:43 GMT
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 <ecki@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.goers@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message