On 27 April 2016 at 17:18, Ralph Goers <ralph.go...@dslextreme.com> wrote: > One thing to be wary of - Most, if not all, of the other Commons projects are > not multi-module projects. I remember specifically having to do “interesting” > things in the VFS pom to fix things that didn’t work correctly in > commons-parent. I am sure over the course of time a lot of that has changed. > But you will probably have some trial and error, which is why I would build > first by manually activating the profiles and not starting with the release > plugin as it is much easier to just blow away the target directory and start > over than it is to revert stuff from scm.
I committed a couple of scripts to the Commons scripts [1] directory a few days ago that might be useful. create_RC_tag.sh - create an RC tag from trunk, leaving trunk alone. No need to revert trunk if there is a problem, just bump the pom RC version and try again. I used this for Validator. Nexus2DistDev.sh - download the bin and src archives from Nexus [1] https://svn.apache.org/repos/asf/commons/scripts > > Ralph > >> On Apr 27, 2016, at 8:31 AM, Josh Elser <josh.el...@gmail.com> wrote: >> >> Thanks, Sebb and Ralph. >> >> I can dig through the parent poms. I wouldn't have initially realized that >> there was a "commons" parent pom. Thanks for pointing that out. >> >> sebb wrote: >>> 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 >>> >> >> --------------------------------------------------------------------- >> 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
