: I think it's fair to say that with the 0.2 release we're still pretty
: much in the transition for the Incubator to Lucene (and from a
: developer-only product to a general end user product). The main drive
...
: made clearly either as an Incubator release or as a Lucene release
: once all the project migration is done. I guess I was the main
: proponent in pushing for the 0.2 release already while the Lucene
: migration was still incomplete.
I think the incubator ship has sailed: Tika has graduated, long live Tika!
Any release after graduation shouldn't include incubator references.
: At least I was pretty vocal about switching to the jar format for our
...
: tarball, at least I would rather fix the documentation than change the
: packaging format.
cool, as long as it was a conscious choice.
: now updated all Incubator references, so any new release will have
: this issue fixed. Given the PMC pushback; perhaps we should just scrap
: the 0.2 release and go directly to 0.3 based on the current trunk?
I don't know enough about how the codelines have progressed to have an
opinion on that, but I'm sure the next release can be *named* 0.2 even if
you guys decide to abandom the current branch.
Based on your email though, it sounds like a few s/incubator/lucene/
changes and another paragraph in the README file is really all that needs
to be "fixed" to make 0.2 releasable (in my opinion anyway)
: documentation isn't complete (e.g. the Getting Started guide didn't
: yet exist in 0.2 release candidate) shouldn't IMHO be a blocker for a
: release (especially for a 0.x one). In any case it's an area where we
: are clearly getting better during the 0.x release cycle.
...
: Currently the guide contains some forward-looking statements about the
: potentially upcoming 0.3 release; mostly that the "standalone" and
Ahhh..... see, my whole confusion was in thinking the docs have been
applicable since 0.1 (I'm starting to really understand why Doug has
argued so strongly in the past that the "main" set of docs a project has
on the site should always be the last official release)
By all means, ship with the documentation you have -- don't hold up a
release waiting to write new docs -- but *something* should be in the
README about how to "use" tika. I've got a suggested path below.
: Apache license header), so at least I prefer to not include the
: license header in those test files. See also
: http://markmail.org/message/m7jmgl3qncsffygb for related discussion on
: [EMAIL PROTECTED]
Ah! ... that's awesome, i'm glad to see that the legal concensus seems to
have changed -- ignore my comment.
: On the other hand, I don't see documentation as being a valid blocker
: for any 0.x release.
Hmmmm... holding up a release until docs get written is silly, but making
sure people know how to find the docs that do exist (particularly when the
ones they'll find if they go searching arround online are significantly
different) seems important.
Suggested PATCH....
diff orig/README.txt hoss/README.txt
67a68,70
> This will created a ./target/ directory containing the Apache Tika
> binary JAR file.
>
70a74,86
> Documentation
> =============
>
> You can build a local copy of the Tika documentation including
> JavaDocs using the following Maven 2 command in the Tika source
> directory:
>
> mvn site
>
> You can then open the Tika Documentation in a web browser:
>
> ./target/site/documentation.html
>
