> -----Original Message-----
> From: Bernd Eckenfels [mailto:e...@zusammenkunft.net]
> Sent: Wednesday, December 03, 2014 6:28 PM
> To: Commons Developers List
> Cc: dlmar...@comcast.net
> Subject: Re: [VFS] Release Preparations 2.1 (again)
>
> 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.
VFS-540 has commit comment from VFS-541.
VFS-476 and VFS-540 are dupes, but both are listed in changes.xml. I
assume one should be marked as a dupe and removed from changes.xml?
VFS-457 is still open.
VFS-415 requires Java 1.6, announcement.vm needs to be updated.
VFS-371 to 391 fixVersion is incorrect (is currently NightlyBuild)
>
> 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).
I don't feel that I know enough about the other providers to know what is
trivial or dangerous. I did update VFS-530 for the HDFS provider though.
>
> c) check out vfs2-project/trunk on various systems (with compiler
> zoo) and try to build it (including site goal).
Linux x64:
'mvn clean package' built successfully with jdk1.6.0_45, jdk1.7.0_72,
jdk1.8.0_25 **
** includes VFS-530-4.patch changes
>
> 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.
The instructions at
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
might resolve the issue. It involves creating another module, want me to take
a crack at it?
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
