Hello, Am Wed, 3 Dec 2014 13:42:51 +0000 (UTC) schrieb dlmar...@comcast.net:
> I'm not sure I can help with tagging and deploying as I don't have > the permissions. However, I'm happy to help test the RC's, confirm > MD5s, and provide non-binding votes. There are a number of housekeeping stuff which needs or should be done. Anybody who likes to help, this would speed up the release. (make sure you post here the results, so we can confirm its done). a) check the src/changes/changes.xml: all action entries with bug numbers since the last release should be marked resolved (not closed - actually all bugs on the jira report should be "resolved") with fix version 2.1. Check which bugs are in the JIRA report with a resolution different from resolved (make it look clean and tidy). Check which bugs are resolved in jira, not mentioned in changes and should be announced as good/critical change. b) check all open JIRA bugs if there are any with a trivial fix or a pending patch or a totally dangerous sounding description (i.e. blocker). c) check out vfs2-project/trunk on various systems (with compiler zoo) and try to build it (including site goal). d) run all test cases which have (Additional) external dependencies profiles (webdav, ftp, hdfs(?), ...) against different test servers. e) Try to use any existing VFS users or providers as binary or source together with the trunk. f) the hadoop equals fix should be tested against a real use (VFS-523) g) check the various site reports of trunk, if anything is critical (PMD, findbugs, Clirr) h) check if the 54 implicte excludes which are mentioned by RAT report (while building site) are actually aceptable. i) run "mvn clean verify" in a loop for a few hours and hunt-down (sporadic) test fails. j) try to build a working project/site for trunk and collect what things need to be done to get all links working* (this especially is a list of things like: "move core/target/site/*" to "target/site/commons-vfs2/*" (or if there is a way to get an aggregated site I dont know (and the current commited vfs2 site does neither: http://commons.apache.org/proper/commons-vfs/commons-vfs2/index.html). k) find out why "mvn -U -x clean site -P release,include-sandbox -DskipPGP=true" fails with a dist/checkstyle-supression.xml problem, report it as a bug and provide a patch (and provide a path) (something around ${vfs.parent} I guess. l) not planning to work on vfs-xxxx before this release, but if m) find out if an easy fix exists to make the broken glassfish repository not show up in the effective pom (to avoid delay and warnings in site build, that annoyed me for quite some time). Gruss Bernd * Is this enough? mv core/target/site target/site/commons-vfs2 mv example/target/site target/site/commons-vfs2-example mv sandbox/target/site target/site/commons-vfs2-sandbox > > ----- Original Message ----- > > From: "Bernd Eckenfels" <e...@zusammenkunft.net> > To: "Commons Developers List" <dev@commons.apache.org> > Sent: Wednesday, December 3, 2014 3:29:45 AM > Subject: Re: [VFS] Release Preparations 2.1 (again) > > Hello, > > I checked the release-plugin documentation and I cannot find a way to > specify different tags for the usage inside the prepared POM and the > Tag which should be used for actually tagging. > > I also think this is pretty uncommon, and I would go with using the > final release version tag (commons-vfs2-project-2.1 or > commons-vfs-2.1 or vfs-2.1 depending on the outcome of the > discusssion). > > As mentioned before, I am fine with having at least one non-final RC > produced using a RC tag and the commons.rc.version=RC1 specified. But > as soon as we think we can produce a result I woul run the release > plugin with the final tag. > > BTW: -P apache-release does not work with VFS as it fails the > source:single execution (missing assembly descriptor which is in > dist/ for VFS). It seems to work with -Prelease, do we want to use > this? > > Gruss > Bernd > > Am Tue, 2 Dec 2014 22:50:03 -0700 > schrieb Ralph Goers <ralph.go...@dslextreme.com>: > > > > > > > > Unfortunately, I don’t believe I > > > > documented the release process but it should be similar to > > > > http://wiki.apache.org/logging/Log4j2ReleaseGuide > > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide> > > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide > > > > <http://wiki.apache.org/logging/Log4j2ReleaseGuide>>, since I > > > > based the Log4j build and release process after VFS. > > > > > > > > > Before we do this, a couple of questions: > > > > > > - how hard is it to delete tags from SVN and who can do that? > > > > > > You should not delete tags from SVN. If you can commit, you can > > > manage tags and branches AFAIK. IMO, the process should be that > > > we VOTE on an RC tag, if the vote passes the RC tag is copied to > > > a release tag. If it fails, you try again with a new RC tag. The > > > tags live in SVN as a record of what we VOTEd on. > > > > > > > I recall that at the time of the 2.0 release the release plugin > > used the same version as the artifact for tagging, but I could be > > wrong. I seem to recall that now the tag does not have to match, so > > what Gary is suggesting should be doable. > > > > Ralph > > > > > > > --------------------------------------------------------------------- > 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
