Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.220.52 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Subject: Re: [VFS] Release Preparations 2.1 (again)
From: Ralph Goers <ralph.goers@dslextreme.com>
In-Reply-To: <547eaf6a.275f8c0a.9b77.ffffd2e3@mx.google.com>
Date: Wed, 3 Dec 2014 08:01:43 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <10EA7BC5-BA22-465D-B4F6-0754A2E06F20@dslextreme.com>
References: <p2dcj2m20ncxw9elbo0l7kmi.1417264951989@email.android.com>
 <366549077.8950860.1417274822157.JavaMail.zimbra@comcast.net>
 <9602086F-3E72-4533-A4DD-F9A520CF2E19@dslextreme.com>
 <20141202235109.000049e8.ecki@zusammenkunft.net>
 <CACZkXPx6iwyjGkb2mUmiB=kJZ8G741tm9MNwuG2d9hLNV_+zqw@mail.gmail.com>
 <C6123334-4940-44FB-8810-0DB973908A95@dslextreme.com>
 <547eaf6a.275f8c0a.9b77.ffffd2e3@mx.google.com>
To: Commons Developers List <dev@commons.apache.org>

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:
>=20
> Hello,
>=20
> 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.
>=20
> 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?
>=20
> Gruss
> Bernd
>=20
> --=20
> http://bernd.eckenfels.net
>=20
> ----- Urspr=C3=BCngliche Nachricht -----
> Von: "Ralph Goers" <ralph.goers@dslextreme.com>
> Gesendet: =E2=80=8E03.=E2=80=8E12.=E2=80=8E2014 06:52
> An: "Commons Developers List" <dev@commons.apache.org>
> Betreff: Re: [VFS] Release Preparations 2.1 (again)
>=20
>>=20
>>> Unfortunately, I don=E2=80=99t 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.
>>=20
>>=20
>> Before we do this, a couple of questions:
>>=20
>> - how hard is it to delete tags from SVN and who can do that?
>>=20
>> 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.
>>=20
>=20
> 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.
>=20
> Ralph
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org