Ask Slashdot: To Publish Change Logs Or Not? 162
Linnerd writes "A software company I work for has decided to no longer publish change logs when updated versions of the software are made available. A change log consists of sections pulled directly from the issue management system that is automatically processed into a spreadsheet. The spreadsheet can be sorted/viewed by many criteria, such as date of the fix, component affected, severity and more. There usually are a fair number of entries (sometimes more than 1000), because each update published contains all the accumulated changes made since some base release in the past and the change log has entries for everything from major bugs to minor improvements to documentation changes and spelling errors fixed. The main reasons for pulling the change logs was the fear of putting the software in a bad light and risking ridicule, especially from the competition. Although I can follow these arguments up to a point, I've personally always been more comfortable with software that had explicit and detailed change logs: Errors and bugs happen, whether they are communicated or not, and I'd rather know what was changed than blindly install some patch without knowing if it's relevant for the issues I'm trying to solve. What is your opinion? Should change logs / errors / bugs be communicated openly? How is this handled in the companies you work for? Can you provide publicly available references on the pros and cons of open and honest communication of changes and bug fixes, especially in commercial environments?"
Re:Change logs matter (Score:5, Interesting)
This is why there are generally 2 sets of change logs (in reality one that derives another set). You have the changelog that is used internally, which is what you are talking about. The other is a list of bug fixes, enhancements, and removed features for customers.
Good internal change logs track not only what was fixed, but what was attempted in the fix process so that you don't replicate these failed paths in later problems/enhancements. Code samples are usually in "good" change logs as well. These things are not needed for a customer, and are probably where you would find the ridicule.
If you are really being told to remove change logs, that is a very broken situation. Those logs are not just to show people you are actively developing your code and fixing things, but also to reduce your overall development costs.
Re:Change logs matter (Score:4, Interesting)
Not only that, but when something goes wrong after upgrading something, it's useful to be able to say "ok, what's changed since the last version...".
Sounds to me like submitter needs to find a middle ground between basically publishing their internal bug tracking and not publishing anything. It can be as simple as having a co-op / intern go through the internal change log and create a sanitized generic-ified version for public consumption (you know, in leu of actual work experience..).