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 <e...@zusammenkunft.net> wrote: > > Hello, > > see inline. > > Am Tue, 26 Apr 2016 18:05:01 -0400 > schrieb Josh Elser <els...@apache.org <mailto:els...@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<e...@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<els...@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<garydgreg...@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<els...@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-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > <mailto:dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > <mailto:dev-h...@commons.apache.org>
