Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
From: Ralph Goers <ralph.goers@dslextreme.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_7B00C2A2-1C7B-4F0E-BE8B-06443A8E73D1"
Message-Id: <F72132A2-CFA8-41DA-96BC-9CA2E2466BC9@dslextreme.com>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: [VFS] 2.1 Release Plan
Date: Tue, 26 Apr 2016 21:58:07 -0700
References: <571E6A9B.40005@apache.org>
 <CACZkXPxzdQ9=LBVJa6JCeGjFn9KO9buqCXh6LTthdsazKopj3A@mail.gmail.com>
 <CACmp6kq1q3PrfKBWOCwDSB29T+pKeQgsuGybP2D9JHJh1WY-kw@mail.gmail.com>
 <571F6FB1.9030503@apache.org>
 <20160426213126.00002115.ecki@zusammenkunft.net>
 <CACZkXPwLEGvjx7zsY-WKK-L1K_SLis8juyrQ4rAz0YAA44dK_w@mail.gmail.com>
 <571FE60D.7040701@apache.org>
 <20160427002703.00006289.ecki@zusammenkunft.net>
To: Commons Developers List <dev@commons.apache.org>
In-Reply-To: <20160427002703.00006289.ecki@zusammenkunft.net>

--Apple-Mail=_7B00C2A2-1C7B-4F0E-BE8B-06443A8E73D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

As I recall, I performed the VFS 2.0 release. I did use the Maven =
release plugin. It has been so long that I have forgotten the details of =
what had to be done, but I know I ended up using it as the model for =
setting up Log4j 2=E2=80=99s build.

As I recall I would sort of test =E2=80=9Cpre-releasing=E2=80=9D by =
running a build with -P apache-release as that profile enables a bunch =
of stuff in the ASF parent pom.

Ralph

> On Apr 26, 2016, at 3:27 PM, Bernd Eckenfels <ecki@zusammenkunft.net> =
wrote:
>=20
> Hello,
>=20
> see inline.
>=20
> Am Tue, 26 Apr 2016 18:05:01 -0400
> schrieb Josh Elser <elserj@apache.org <mailto:elserj@apache.org>>:
>=20
>> Thanks for the great details, Bernd. Some questions/comments:
>>=20
>> I hadn't even stumbled across VFS-570 due to its lack of
>> fixVersion=3D2.1. Are there more that need to be correctly tagged =
which
>> could potentially block the release of 2.1?
>=20
> I did not waste much time in setting/unsetting the fixversion. I
> modified some severities and closed some. But the blocker bugs (the
> ones I considered) are all closed.
>=20
> You could do a mass change on the existing bugs, but I am sure that
> causes some discussion and especially people setting the fields back =
to
> their preferences (at least that happend a few times in the past).
>=20
>> I'm not sure I follow you about the concern of using=20
>> maven-release-plugin with a multi-module maven project. This works
>> just fine (@see other Apache maven projects I'm involved in). If
>> there are demons laying in wait, I can knock them out as I find them.
>=20
> Well yes, I use the release plugin aswell (in fact I did a company
> internal release of VFS 2.1 with it already). I think it was also used
> for the 2.0 release. But there are some things (especially the tagging
> of the SVN and the tag in the POM) which is currently not very
> preferable in apache commons I think. I would not use it for a release
> (especially as rolling back and revovering would be painful). But I
> agreee with you, it should work.
>=20
>> Are there instructions on running clirr? I'm not familiar with the
>> tool (and I don't see any configuration in the top-level pom.xml).
>=20
> You can run the "mvn -Psandbox clean site" build (possibly follwoed by
> a site tst deploy). The clirr report is part of it. I had a site build
> from the snapshot on people.apache.org <http://people.apache.org/>, =
but I havent checked if/how the
> new server would look like. So currently you need to run it locally.
>=20
>> Do you have the karma to make a 2.2 version on JIRA? That'd be a nice=20=

>> help to start moving stuff out of 2.1 (as well as make sure things=20
>> sitting in Patch Available don't get forgotten).
>=20
> Yes, seems like I can do it. I created 2.2.
>=20
>> I would lean towards=20
>> the side of only putting bug-fixes into a 2.1.1 and preferring
>> towards any new features/changes into a 2.2 (to closer follow the
>> definition of semver). We presently have 3 major and 1 minor version
>> unresolved for fixVersion=3D2.1 -- these where the issues I =
previously
>> referred to that I felt OK bumping out as well.
>=20
>> Gary -- "BC breakage" =3D=3D base-class breakage? As in: the common=20=

>> base-class for all of the VFS Providers has changed (and would
>> require changes from anyone downstream that has built their own)?
>=20
> It refers to (binary) backward compatibility. For a client a new =
method
> in an interface is a compatible change which fits into a minor update.
> However when you have to implement a interface as a VFS provider you
> wont be binary and source compatible. For most classes it is not a
> problem since the mehtod is provided by the AbstractBaseClass for an
> interface (but not all Interfaces have that and it was never mandatory
> for an provider to use them).
>=20
>> I can try to start pounding on an initial RC in the evenings this
>> week. I'll be sure to reach out as I need some more help/karma ;)
>=20
> Anything more needed from me?
>=20
> Gruss
> Bernd
>=20
>=20
>>=20
>> Gary Gregory wrote:
>>> Yes, there is a BC breakage for providers, is that grounds for a
>>> package and Maven coordinate rename to vfs3?
>>>=20
>>> Gary
>>>=20
>>> On Tue, Apr 26, 2016 at 12:31 PM, Bernd
>>> Eckenfels<ecki@zusammenkunft.net> wrote:
>>>=20
>>>> Hello Josh,
>>>>=20
>>>> I think a VFS 2.1 release would be cool and it is good that you
>>>> volunteer, so I dont object. My latest todo list is here:
>>>>=20
>>>> https://wiki.apache.org/commons/VfsReleaseState
>>>>=20
>>>> As you can see, I did plan to do the release and did quite some
>>>> work to get VFS into a releaseable state. But I am quite happy
>>>> that you want to step in as I havent had the time to do the
>>>> procedure yet.
>>>>=20
>>>> And this is not the actual release procedure (which should be
>>>> doable as long as you do not try to use the release-plugin and be
>>>> careful about the multi-module+sandbox nature of VFS (as opposed
>>>> to other commons projects)). Also be carefull about branch and tag
>>>> namings (the SVN is a bit messy in this regard).
>>>>=20
>>>> My main concern I am afraid I would not have enough capacity is
>>>> because of the Clirr report and a lot of partially incompatible
>>>> changes. Most of them only affect providers if they do not
>>>> properly use abstract base classes, but still the list of Clirr
>>>> violations is long and developers here have not yet voiced if they
>>>> would accept a RC with this situation (or not).
>>>>=20
>>>> Anyway, I do agree that the current critical and blocker bugs are
>>>> important but should not stop the 2.1 release (especially if a
>>>> 2.1.1 release aferwards is much faster to do.) It would be cool to
>>>> have VFS-570 (write suport for VFS, but even that could be
>>>> delivered with 2.1.1 - it might annoy the HDFS folks a bit)
>>>>=20
>>>> So I can help you in case you need me to sponsor some changes (I
>>>> hope I have enough karma now).
>>>>=20
>>>> We could even make a joined RC1, I am just not sure it wont open a
>>>> big chunk of additional work.
>>>>=20
>>>> Gruss
>>>> Bernd
>>>>=20
>>>>  Am Tue, 26 Apr 2016 09:40:01 -0400
>>>> schrieb Josh Elser<elserj@apache.org>:
>>>>=20
>>>>> Thanks Matt and Gary.
>>>>>=20
>>>>> I do recall seeing the asf-wide note that my commit-bit also
>>>>> applies to commons-*. Thanks for bringing that up. Specifically
>>>>> though, I am only interested in cutting a release -- if we can
>>>>> get a new release cut that we can use downstream, that increases
>>>>> the likelihood that I will have more things to contribute back :)
>>>>>=20
>>>>> I'll pull up the thread in the archives and get back to ya'll with
>>>>> any questions I have after that.
>>>>>=20
>>>>> - Josh
>>>>>=20
>>>>> Matt Sicker wrote:
>>>>>> It's from the thread called "Whatever happened to commons-io
>>>>>> 2.5?" A few people stepped up to give the necessary permissions
>>>>>> and committed his GPG key.
>>>>>>=20
>>>>>> On 25 April 2016 at 17:10, Gary Gregory<garydgregory@gmail.com>
>>>>>> wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> Agreed, VFS 2.1 has been too long in the making. We can release
>>>>>>> ASAP without fixing more bugs IMO. RERO and all.
>>>>>>>=20
>>>>>>> As an Apache committer, your are also an Apache Commons
>>>>>>> committer, so feel free to create JIRAs, fix bugs and so on.
>>>>>>>=20
>>>>>>> There might be some karma issues with a non-PMC member
>>>>>>> performing a release, and I think we just went through this
>>>>>>> (sorry, I'm in settling in a new house, not much time to dig in
>>>>>>> the ML archives).
>>>>>>>=20
>>>>>>> Does anyone recall?
>>>>>>>=20
>>>>>>> Gary
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<elserj@apache.org>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> Hi all,
>>>>>>>>=20
>>>>>>>> There are presently 171 resolved issues sitting in commons-vfs2
>>>>>>>> 2.1-SNAPSHOT, with 4 outstanding (none of which look like
>>>>>>>> blockers to
>>>>>>> me).
>>>>>>>> The lack of any release of commons-vfs2 in years has been a big
>>>>>>>> problem downstream. This past weekend, I was again annoyed by
>>>>>>>> bugs that have been fixed (but not release) which is spurring
>>>>>>>> me to take some action. There have been emails reaching back
>>>>>>>> as far as 2014 asking when the next
>>>>>>> release
>>>>>>>> might be, not to mention the fact that vfs-2.0 was released in
>>>>>>>> 2011 (!).
>>>>>>>>=20
>>>>>>>> History aside, I'm reaching out today to:
>>>>>>>>=20
>>>>>>>> 1) See if anyone on the PMC has the cycles to volunteer as RM.
>>>>>>>>    1a) If not, how can you empower me (or others) to make the
>>>>>>>> release on your behalf.
>>>>>>>> 2) Understand, specifically, what (if any) roadblocks exist to
>>>>>>>> release this version.
>>>>>>>>=20
>>>>>>>> Thanks.
>>>>>>>>=20
>>>>>>>> - Josh
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> =
---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second
>>>>>>> Edition<http://www.manning.com/tahchiev/> Spring Batch in
>>>>>>> Action<http://www.manning.com/templier/> Blog:
>>>>>>> http://garygregory.wordpress.com Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>> =
---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>=20
>>>>=20
>>>> =
---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org =
<mailto:dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org =
<mailto:dev-help@commons.apache.org>

--Apple-Mail=_7B00C2A2-1C7B-4F0E-BE8B-06443A8E73D1--