Hi Folks, My +1 for having a CHANGES.txt file, for all the reasons that Yonik mentioned below. Also, it, to me, is much easier to maintain (simply doing it incrementally, with each major update), then figuring out the mysteries of JIRA ;)
So, I'd like to call for a vote from the committer community. Should we use a CHANGES.txt file? (please mark an X by your choice) [ ] Yes [ ] No Let's leave the vote open until we have a majority of binding votes. Thanks! Cheers, Chris On 6/12/07 12:38 PM, "Yonik Seeley" <[EMAIL PROTECTED]> wrote: > On 6/12/07, Sami Siren <[EMAIL PROTECTED]> wrote: >> 2007/6/12, Jukka Zitting <[EMAIL PROTECTED]>: >>> On 6/7/07, Chris Mattmann <[EMAIL PROTECTED]> 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&styleN >> ame=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. > > Examples: > > 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) > > and > > 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. > > -Yonik
