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] 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.

Ralph

> On Apr 26, 2016, at 3:27 PM, Bernd Eckenfels <ecki@zusammenkunft.net> wrote:
> 
> Hello,
> 
> see inline.
> 
> Am Tue, 26 Apr 2016 18:05:01 -0400
> schrieb Josh Elser <elserj@apache.org <mailto:elserj@apache.org>>:
> 
>> 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 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.
> 
>> 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<ecki@zusammenkunft.net> 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:
>>>> 
>>>> https://wiki.apache.org/commons/VfsReleaseState
>>>> 
>>>> 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<elserj@apache.org>:
>>>> 
>>>>> 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<garydgregory@gmail.com>
>>>>>> 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
in
>>>>>>> the ML archives).
>>>>>>> 
>>>>>>> Does anyone recall?
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<elserj@apache.org>
>>>>>>> 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
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 (!).
>>>>>>>> 
>>>>>>>> History aside, I'm reaching out today to:
>>>>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> - Josh
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>> 
>>>>>>>> 
>>>>>>> --
>>>>>>> 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
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>>> 
>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> 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>

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