On Wed, Oct 26, 2011 at 2:03 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > On Thu, Oct 20, 2011 at 2:26 PM, Michael McCandless > <luc...@mikemccandless.com> wrote: >> But I think API changes, issues a user has hit, new features, changes >> in behavior, we really should include. Generally, when I'm unsure, I >> try to err on the side of "being verbose". > > See revision 1189334 for how we can improve the readability of the > change log without reducing the amount of raw information included.
Ooh, that looks great, thanks! Maybe, we can inline the references to the issues, so the user knows which is which? EG: * PDF: The PDF parser now extracts paragraphs within each page (TIKA-742) and can also optionally extract text from PDF annotations (TIKA-738). There's also an option to enable (the default) or disable auto-space insertion (TIKA-724). We all should feel free to go refactor CHANGES.txt whenever it needs it; it shouldn't always have to fall onto the RM at release time. >> In addition to conveying what's new about the release, this also gives >> potential upgraders a simple measure of how active/healthy Tika dev >> is, and so another good reason to include a change is to convey that >> we are in fact healthy. We shouldn't undersell ourselves, and, the >> perceived health of the dev community by our users is important, I think. > > +1 > >> Your idea would be AWESOME! Has anyone added a custom field to >> Jira...? How hard is it...? In theory it doesn't look too bad: > > There even is a Change Log field buried inside the ASF Jira > configuration (you can see it in the field admin screen), but so far I > haven't figured out how to make it active in a project. > > Anyway, like shown in revision 1189334, I'm not convinced that an > automatic Jira report can produce very readable output. Even with more > text per issue, the list will look and read pretty much like the raw > change lists we had for the 0.1 and 0.2 releases. OK I agree... we'll need the freedom to massage it over time. Let's leave it manually edited / refactored. >> We can also do this with add-CHANGE-as-you-go, ie you just refactor >> the CHANGES as needed, or don't put a CHANGE entry in until you're >> done with all the related issues, etc. > > I guess ideally we should always update the change log whenever > something non-trivial and user-visible changes. Refactoring entries > like I did in revision 1189334 should also be preferred whenever > there's a good chance for that. > > We haven't really lived up to such an ideal lately, but big +1 for > bringing this up and leading the way! OK thanks Jukka! This is an exciting time for Tika... lots of changes lately, 1.0 release coming... Mike
