Hi, 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. > 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. > 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! BR, Jukka Zitting
