lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven A Rowe <>
Subject CHANGES.txt
Date Fri, 17 Apr 2009 17:46:40 GMT
A few random observations about CHANGES.txt and the generated CHANGES.html:

- The "ü" in Christian Kohlschütter's name is not proper UTF-8 (maybe it's double-encoded
or something) in the two LUCENE-1186 mentions in the Trunk section, though it looks okay in
the LUCENE-1186 mention in the 2.4.1 release section.  (Déjà-vu all over again, non?)

- Five issues (LUCENE-1186, 1452, 1453, 1465 and 1544) are mentioned in both the 2.4.1 section
and in the Trunk section.  AFAICT, it has not been standard practice to mention bug fixes
on a major or minor release (which Trunk will become) if they are mentioned on a prior patch

- The perl script that generates Changes.html ( finds list items using a regex
like /\s*\d+\.\s+/, but there is one list item in CHANGES.txt (#4 under Bug fixes in the Trunk
section, for LUCENE-1453) that doesn't match this regex, since it's missing the trailing period
(" 4 "), and so it's interpreted as just another paragraph in the previous list item.  To
fix this, either the regex should be changed, or " 4 " should be changed to " 4.".  (I prefer
the latter, since this is the only occurrence, and it has never been part of a release.)

- The Trunk section sports use of a new feature: <code> sections, for the two mentions
of LUCENE-1575.  This looks fine in the text rendering, but looks crappy in the HTML version,
since escapes HTML metacharacters to appear as-is in the HTML rendering, but
the newlines in the code are converted to a single space.  I think this should be fixed by
modifying to convert <code> and </code> into (unescaped) <code><pre>
and </pre></code>, respectively, since just passing through <code> and </code>,
without </?pre>, while changing the font to monospaced (nice), still collapses whitespace
(not nice).  (There is a related question: should all HTML tags in CHANGES.txt be passed through
without being escaped?  I don't think so; better to handle them on a case-by-case basis, as
the need arises.)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message