tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <yo...@apache.org>
Subject Re: Tika Changelog
Date Tue, 12 Jun 2007 16:38:25 GMT
On 6/12/07, Sami Siren <ssiren@gmail.com> wrote:
> 2007/6/12, Jukka Zitting <jukka.zitting@gmail.com>:
> > On 6/7/07, Chris Mattmann <chris.mattmann@jpl.nasa.gov> wrote:
> > > I've created a Tika changelog, CHANGES.txt, within the TIKA trunk that we
> > > can use to track changes, akin to Nutch. Typically, when a committer commits
> > > a patch (in Nutch) that closes out a tracked issue (i.e., with JIRA), then
> > > we add a comment into CHANGES.txt, akin to the following (where "n" is a
> > > number incremented from 1, for each release):
> >
> > I think it's just duplicating information from the svn log, but if
> > people think it's a good idea, then I have no problem following suit.
> Jira can also provide a list of changes (if all changes are logged
> there) with the changelog - or release notes [1] functionality.
> [1] http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312013&styleName=Text&projectId=10680&Create=Create

I personally use CHANGES.txt in Lucene and Solr as user-level
documentation / release notes.  If it's too minor, an internal
cleanup, a documentation fix, etc, I don't put it in.  It also
provides a place to concisely explain the impact of a change (in user
language), rather than requiring the user to try and glean this from a
long JIRA discussion mingled with dev-list discissions.


 3. SOLR-91: allow configuration of a limit of the number of searchers
    that can be warming in the background.  This can be used to avoid
    out-of-memory errors, or contention caused by more and more searchers
    warming in the background.  An error is thrown if the limit specified
    by maxWarmingSearchers in solrconfig.xml is exceeded. (yonik)


 3. LUCENE-710: added optional autoCommit boolean to IndexWriter
    constructors.  When this is false, index changes are not committed
    until the writer is closed.  This gives explicit control over when
    a reader will see the changes.  Also added optional custom
    deletion policy to explicitly control when prior commits are
    removed from the index.  This is intended to allow applications to
    share an index over NFS by customizing when prior commits are
    deleted. (Mike McCandless)

It's much more understandable then a JIRA bug list, but it does take more work.
If you wish to go this route, you could perhaps defer it until the
first Tika release.


View raw message