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?"
Nope (Score:2, Informative)
I won't install an update without a change log.
Compliance requirements (Score:4, Informative)
From where I sit there's no question: for compliance reasons we must be able to detail exactly what is being changed when we install updates to software. If we can't, then we have to re-certify the software from scratch before it can be deployed which is a fairly tedious and time-consuming process. Having to do that with any regularity will find us looking for alternatives.
As for a list of bug-fixes making your software look bad, remember this: I know exactly how long our unresolved-issues list is for every single bit of commercial software we use, and exactly how long some of those issues have been sitting there. That your software has bugs that needed fixed too isn't going to come as any great surprise to me. What will impress me is a) actually fixing problems, and b) being clear about what you're fixing or changing which minimizes the amount of work I get saddled with.
Re:Change logs matter (Score:4, Informative)
Most folks call those edited change logs "release notes" in my experience. The list of changes, defect fixes, etc. should at least be a section in overall release notes, but they don't usually have to go into gory detail the way that the OP describes. The change or defect number being fixed is always useful, because then you can lookup the original bug report online for more details if you think it might impact your environment,.
Re:Your customers are lucky (Score:5, Informative)
This is a practice that has been drilled into my head: any half-thoughts, offhand comments, or speculation can very, very easily be manipulated by a lawyer to make you or your company look like a guilty guilty liars in a courtroom. One excerpt from a change log, blown up onto a 4' x 6' poster, displayed in front of a jury, can result in a multimillion-dollar loss for you or your company. Never mind that the full context would exonerate you or that there's a larger story surrounding that comment - the opposing lawyer only needs to keep pointing to that poster to make you look like an idiot that's got something to hide.
Now, it is bad enough for such potentially dangerous content to exist in materials that are discoverable once a lawsuit has already begun. It is downright stupid, as a business practice, to just put those materials out in the wild for anyone to examine and look for something that could be sued over. If you want to keep your customer informed about what's changed, by all means produce a formal document that does that, with detail to the nth degree. The change logs are for internal use; they aren't for your customers.