HI, On Dec 24, 2007 6:47 PM, Chris Mattmann <[EMAIL PROTECTED]> wrote: > > I can't see any issues with the release candidate but it would be nice > > for windoze users to include "zip" distro - also wouldn't it be nice > > for users to also release binary distros and not just the source > > distro? > > We (Jukka, Bertrand, Sami) discussed this earlier, and the consensus was to > make the tika jar file available from a maven repository somewhere. So, > that's what we're going with for 0.1.
I'm with Niall on that we should include the Maven artifacts in the release vote. I've built the artifacts from the 0.1-incubating release candidate you posted and deployed them to a staging repository at http://people.apache.org/~jukka/tika/0.1-incubating/repository/. I've also signed the artifacts (jar and pom) with my key, so unless we want to scrap this vote and start a new one after a few changes (see below) we could just consider these artifacts as being within the scope of this vote. > > Couple of other minor points: > > > > 1) CHANGES.txt says "Unreleased changes (0.1-dev)" rather than > > indicating the 0.1-Incubating release > > This will be updated before I officially tag the branch, and make the > release. We can't be voting on a release and then have changes made to it before it goes out. The vote needs to happen on the actual bytes that we will be publishing. I suggest we make the suggested changes, tag and package the modified release candidate, and restart the vote in a "[VOTE]" thread (it's good practice to use that subject tag to make the vote threads easier to filter and find). > > 2) Usual convention I've seen on other projects is to use "tags" for > > releases and "branches" for alternative development branches: > > http://svn.apache.org/viewvc/incubator/tika/branches/ > > I've seen both conventions on projects for this. In my mind, it makes sense > to first branch, then if there are any issues during rc evaluation, and > patches need to be applied, the patches can be first applied to the branch. > Once an rc is accepted by the committers, then, the branch is tagged as "the > release". Then, if there are any more changes to a particular product line, > the same cycle ensues (update branch, come to agreement, tag branch as > "release"). See my above point about the release vote happening on the actual bytes that get released. Thus there is nothing you should (can!) modify after the vote passes, and so tagging the release already before the vote and actually using the contents of that tag when packaging the release candidate is good practice. In Jackrabbit I even tag x.y.z-rcN candidates that I only post for preliminary review before starting the release vote on a x.y.z candidate package. See https://svn.apache.org/repos/asf/jackrabbit/tags/ for example. > > 3) The IPMC will probably ask to see a RAT report - the site build > > includes one (and it looks fine) - so might be a good idea to either > > stage the site built from that tag or just produce a text one manually > > - I have produced a text one from the 0.1-incubating source distro > > here if that makes life easier: > > http://people.apache.org/~niallp/Tika-0.1/ The RAT output points out a few resources (tika-config.xml, log4j.properties) that should have a proper license header. IMHO this is not a blocker for the release, but I'll be filing an issue for that in Jira and fixing it in trunk. If you like we can merge the change to the 0.1 branch. BR, Jukka Zitting
