On 27 April 2016 at 05:58, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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.
Commons Parent has a -P release profile which is different. I'm not sure CP works all that well with apache-release which does not support everything we expect. You can use -Ptest-deploy to change the deploy target to target/deploy and compare the two. You may need to use 'mvn package deploy' rather than plain 'mvn deploy' if the VFS pom creates any jars in the package phase. > 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> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
