commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [VFS] 2.1 Release Plan
Date Wed, 27 Apr 2016 04:58:07 GMT
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’s build.

As I recall I would sort of test “pre-releasing” by running a build with -P apache-release
as that profile enables a bunch of stuff in the ASF parent pom.


> On Apr 26, 2016, at 3:27 PM, Bernd Eckenfels <> wrote:
> Hello,
> see inline.
> Am Tue, 26 Apr 2016 18:05:01 -0400
> schrieb Josh Elser < <>>:
>> Thanks for the great details, Bernd. Some questions/comments:
>> I hadn't even stumbled across VFS-570 due to its lack of
>> fixVersion=2.1. Are there more that need to be correctly tagged which
>> could potentially block the release of 2.1?
> 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.
> 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).
>> I'm not sure I follow you about the concern of using 
>> 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.
> 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.
>> 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).
> 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 <>, but I havent
checked if/how the
> new server would look like. So currently you need to run it locally.
>> Do you have the karma to make a 2.2 version on JIRA? That'd be a nice 
>> help to start moving stuff out of 2.1 (as well as make sure things 
>> sitting in Patch Available don't get forgotten).
> Yes, seems like I can do it. I created 2.2.
>> I would lean towards 
>> 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=2.1 -- these where the issues I previously
>> referred to that I felt OK bumping out as well.
>> Gary -- "BC breakage" == base-class breakage? As in: the common 
>> base-class for all of the VFS Providers has changed (and would
>> require changes from anyone downstream that has built their own)?
> 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).
>> 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 ;)
> Anything more needed from me?
> Gruss
> Bernd
>> Gary Gregory wrote:
>>> Yes, there is a BC breakage for providers, is that grounds for a
>>> package and Maven coordinate rename to vfs3?
>>> Gary
>>> On Tue, Apr 26, 2016 at 12:31 PM, Bernd
>>> Eckenfels<> wrote:
>>>> Hello Josh,
>>>> 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:
>>>> 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.
>>>> 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).
>>>> 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).
>>>> 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)
>>>> So I can help you in case you need me to sponsor some changes (I
>>>> hope I have enough karma now).
>>>> We could even make a joined RC1, I am just not sure it wont open a
>>>> big chunk of additional work.
>>>> Gruss
>>>> Bernd
>>>>  Am Tue, 26 Apr 2016 09:40:01 -0400
>>>> schrieb Josh Elser<>:
>>>>> Thanks Matt and Gary.
>>>>> 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 :)
>>>>> I'll pull up the thread in the archives and get back to ya'll with
>>>>> any questions I have after that.
>>>>> - Josh
>>>>> 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.
>>>>>> On 25 April 2016 at 17:10, Gary Gregory<>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>> Agreed, VFS 2.1 has been too long in the making. We can release
>>>>>>> ASAP without fixing more bugs IMO. RERO and all.
>>>>>>> As an Apache committer, your are also an Apache Commons
>>>>>>> committer, so feel free to create JIRAs, fix bugs and so on.
>>>>>>> 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
>>>>>>> the ML archives).
>>>>>>> Does anyone recall?
>>>>>>> Gary
>>>>>>> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<>
>>>>>>> wrote:
>>>>>>>> Hi all,
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 2011 (!).
>>>>>>>> History aside, I'm reaching out today to:
>>>>>>>> 1) See if anyone on the PMC has the cycles to volunteer as
>>>>>>>>    1a) If not, how can you empower me (or others) to make
>>>>>>>> release on your behalf.
>>>>>>>> 2) Understand, specifically, what (if any) roadblocks exist
>>>>>>>> release this version.
>>>>>>>> Thanks.
>>>>>>>> - Josh
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> For additional commands, e-mail:
>>>>>>> --
>>>>>>> E-Mail: |
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <>
>>>>>>> JUnit in Action, Second
>>>>>>> Edition<> Spring Batch
>>>>>>> Action<> Blog:
>>>>>>> Home:
>>>>>>> Tweet!
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: <>
> For additional commands, e-mail: <>

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