Hi, On Wed, Oct 19, 2011 at 6:57 PM, Michael McCandless <luc...@mikemccandless.com> wrote: > Or... are you saying CHANGES should not include "minor" issues? Only > "big" ones? And users need to go to Jira to get a complete list?
Yes, basically. If you're doing something that you think the average user of Tika should be aware of when upgrading, then that information should be mentioned in CHANGES.txt. If it's a minor thing that only affects a rare corner case, then it's IMHO better left in Jira. That's just me though. I'm fine also with other approaches to CHANGES.txt. > Ie this has changed from a discussion on "when should we add the > entries to CHANGES" (on committing the change vs at release time) to a > question of "what should CHANGES contain". In a way yes, but those questions are linked: If we choose to record information about all (or most) changes in CHANGES.txt, then we should IMHO rather add a separate field to Jira for such notes and have the CHANGES.txt generated automatically from those records. Otherwise we essentially just maintain two different issue trackers. If on the other hand, as I suggest, the CHANGES.txt is more of an edited summary of the most notable developments since the previous release, it's best maintained manually. And while updating the file right after making a change is a good idea for some things, for others it may actually be better to hold back for a while to get a better big picture of all the related changes. For example, for 0.10 I added the following single entry shortly before the release: * Handling of temporary files within Tika was much improved (TIKA-701, TIKA-654, TIKA-645, TIKA-153) This IMHO gives an average user a much better overall idea of what happened than a detailed listing of each individual change would have done. BR, Jukka Zitting
