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?"
Your customers are lucky (Score:5, Insightful)
Re:Your customers are lucky (Score:5, Funny)
Your customers are lucky, they get to know that something changed. If you were making 'cloud' software, they wouldn't know anything changed until they logged in one morning and things are broken.
Worse yet, they could get a screen full of MyCleanPC spams mixed in with their data.
Re: (Score:2)
Re:Your customers are lucky (Score:4, Funny)
I block MyCleanPC spam with a hosts file. Thank you for being a cosmonaut.
Re: (Score:1)
Re: (Score:3)
Your customers are lucky, they get to know that something changed. If you were making 'cloud' software, they wouldn't know anything changed until they logged in one morning and things are broken.
Not sure you need that much detail to know something is happening and something changed.
Many companies just mention "bug fixes" as a general category that covers typos or potential problems that no one has actually reported.
We just mention things that users have reported, improvements they have asked for, and limitations that were removed and new capabilities added.
We've issued some updates with the single statement "Bug Fixes".
We've issued other updates that require extensive documentation changes as well
Not exactly cloud, but kinda (Score:5, Insightful)
We make a SaaS application. Every major release comes with a change log. Not the raw, unedited and complete change log TFA talks about, but a human readable, edited one of the form
- feature we promised
- change you asked for
- other change you asked for
- new surprise feature
- UI improvement foo
and finally....
- numerous bug fixes
Bugfix releases don't have a separate published change log. Instead, customers who reported a bug are notified directly when it has been fixed.
This way it is useful for the customer. What the customer really wants to know is that they're not paying you for drinking coffee. They don't want information overload. A complete change log would only make sense to people who work with the code.
Re: (Score:2)
What the customer really wants to know is that they're not paying you for drinking coffee. They don't want information overload. A complete change log would only make sense to people who work with the code.
What the customer really needs to know is that if they don't pay up front so the coders can drink coffee, then they won't have to worry about information overload or feature notification systems.
Additionally: If your customer is technical, give them the change log. If they are not, then give them a bullet list and access to the change log. If they don't understand it whey won't read it. If they do understand it, they probably won't read it unless something breaks. Additionally, let me know if you need af
Re: (Score:2)
Re:Not exactly cloud, but kinda (Score:5, Insightful)
Those are called release notes.
Unless it's an extremely specialized application that requires the customer to have expertise in a specialized field, most customers will be perfectly happy with release notes. The gritty details about changes are mostly needed for things like changes to an API, changes to an algorithm that affect calculations, etc.
Re: (Score:2)
I normally just go back over the commit history for our source control (Subversion) and pull stuff out of that. A typical change log looks like this:
- Fixed accidental HD format when saving
- Update to page 97 of EULA, force users to agree again
- dfhdskljfhdsuifh
- Merged changes from lkjvjbhlkvbvk
Re: (Score:2)
That's handled by the bug tracker. Depending on how bugs are filed, it can be external notifications (which may or may not allow direct editing, or just notification only) in which case the customer knows immediately when the fix h
Re: (Score:3)
5 million businesses [google.com] on Google for a start.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
The bank pays interest.
At under the inflation rate.
Re: (Score:2)
Re: (Score:2)
Yeah, I would say that the Nigerian prince is a risky investment.
Re:Your customers are lucky (Score:4, Insightful)
I guess playing devil's webmaster, would there be any possible NEGATIVE consequence of publishing the change log? I don't see it for most applications.
Liability.
Client X has some kind of trouble, looks through the changelog and finds bug Z was fixed and (at least on the surface) appears to have been related.
Most of the time when you're dealing with proprietary solutions (not just software), you don't give the client a full detail of what happened when something went wrong. You go through management to prepare a formal RFO (reason for outage), that way they can clear it with the Legal team, Sales teams, and verify the accuracy of the statement.
Re: (Score:3)
So the liability would be that your lies may be exposed? If no one lied, there would be no liability in telling the truth.
Re:Your customers are lucky (Score:5, Insightful)
I see your point. But liability and truth are not the same thing, and losing in court has nothing to do with truth either.
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.
Re:Your customers are lucky (Score:4, Insightful)
The change logs are for internal use; they aren't for your customers.
I'm not going to be one of your customers, then. I check the changelogs of every Cisco IOS update I deploy. If they changelog isn't published yet, I don't deploy.
I'm not going to add risk to my environment if all the new version did was fix bugs in features I don't use and add new features (with new bugs) that I won't use.
Re: (Score:2)
I don't agree with this logic. If that tactic of hammering on the one liner works, it points to a problem with your own legal team and message, or perhaps to the adversarial court system if you are not being granted an opportunity to tell the full story. Or, could it be that your organization has been negligent and deserves to lose the court case? If not, hiding and burying information doesn't seem like a good idea. That can make you look even worse if the opposition succeeds in showing that you have mo
Re: (Score:2)
How bad are your company's lawyers, that they can't simply show on a 4' x 6' poster the contract terms "not liable for bugs, even if known" and win a lawsuit about a bug?
Nope (Score:2, Informative)
I won't install an update without a change log.
Wild guess.... Equallogic programming team (Score:1)
*after* being acquired by dell. If you've worked with that equipment, you know what I'm talking about.
Change logs matter (Score:5, Insightful)
Anybody who has run software on a non-trivial scale knows how important changelogs are.
They give you some idea of what to expect, but more importantly let you know whether a problem you're having now has been fixed in the upgrade. Although developers would like everyone to run the newest version of software, in practice you don't touch production systems without good reason. Fixed pain points, and maybe security (depending on isolation) are valid reasons. "Because it's there" is not.
Elimination is a stupid move. It's a triumph of marketing at the cost of we who must run this shit.
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:5, Insightful)
Code samples are usually in "good" change logs as well.
Code samples for what? The library your selling? I don't think i've ever put a "code sample" in a changelog for human consumption. That is probably because everywhere I've worked, one of the first things I make sure works is a way for the source management, bug tracking, and release management systems to reference each other. That way, the internal change log has references to the bugs and patches. Curious what the code change associated with something is? Click the link and look at the diffs.
Re: (Score:2)
Re: (Score:2)
No two sites work the same with version control, and I have seen both extremes. At the DOD all code was developed inside of Rational/Clearcase so all work, including failed paths, was fully tracked. That is a rare and expensive way to work. Outside of the DOD, I have seen small sites that only put tested code destined for release into version control, and the only tracking of failures is in the change logs.
I'm assuming based on the topic that this person works at the latter type of site.
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: (Score:3)
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,.
True, and probably a good idea to have this pointed out to them. TFA describes releasing the full change logs to public scrutiny so I'm not sure that they understand the difference.
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..).
Re:Change logs matter (Score:5, Insightful)
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...".
No, you do that before you upgrade and you use the changelog to determine whether you should upgrade at all. If you're doing it in reverse, its your own damn fault.
Re: (Score:2)
Right, because a problem has never come up despite prior testing...
_Obviously_ you check/test before hand, but when problems happen anyway it's good to go back and see what has changed to narrow down the cause. Sometimes just knowing that they were playing with an area of code is helpful, even if the change has nothing to do with the functionality you are interested in.
Re: (Score:2)
Right, because a problem has never come up despite prior testing...
You are absolutely right that change logs are one part of a suite of tools / information sources we use when tracking a bug or problem. But out here in the real world I really do see way too many cases of the reverse. Install without thinking, then check the change log to try and salvage what is left of your ego.
Re: (Score:2)
Fads come and go. Some people get rich off the fads, and we all are envious. But at the end of the day, you end up working in a niche where you survive based on the goodwill of the regular customers you develop and your reputation.
If you're concerned now about the competition, it sounds like your product has gotten successful enough that there is a community that relies on the expectations of what your software will do. If changelogs are making you lose new business, I question who those new businesses ar
Re: (Score:2)
Elimination is a stupid move. It's a triumph of marketing at the cost of we who must run this shit.
There is no shortage of stupid when it comes to big companies due to bureaucracy and those being in management being disconnected from their customers and employees.
I used to work for a small software company of no more then maybe 120 people tops.
It was great; the benefits were great, the people were great and the work was not only great but deeply rewarding and even us low level developers got to have input on the product and even on occasion make design decisions.
Even the top management worked with
Re: (Score:2)
Elimination [of change logs] is a stupid move. It's a triumph of marketing at the cost of we who must run this shit.
(I'm going to borrow the scatological terminology, my apologies but I think serves the purpose)
Hiding the shit is absolutely no proper solution to the problem: it is going to stink anyway and also has chances to create a culture of complancency (if one doesn't see it, we can continue to live in this shit, we got used to the stench anyway).
However... the above being said, let's change a bit the perspective...
if one would be looking to address the root causes of the problem (as in "Why is this shit is there
Re: (Score:3)
Elimination is a stupid move. It's a triumph of marketing at the cost of we who must run this shit.
And make no mistake: it will be elimination. Elimination of your software from many clients' servers / desktops.
People like me won't run your software anymore. I cannot risk having your developers changing code running on my critical systems without so much as telling me what they change. I can usually infer the 'why', but they must tell me the 'what'. You don't mention if your customers have access to the code source or not, but in either case a concise human-formatted changelog is such a basic requirement
Definitely (Score:5, Insightful)
Change logs and proper release notes are very appreciated by administrators and end users. Disclosure of known issues is particularly valued, and it also benefits the vendor because it reduces nuisance calls to technical support. Fixed, pending and wontfix lists are especially appreciated by sysadmins, since they are the ones most immediately impacted by the change - do they install the patch and deploy it immediately, or do they live with the current build until pending issues are fixed, etc.
Plus, it instills trust. A veil of secrecy does not earn trust from your customers, nor does a vague "fixed misc. bugs and implemented misc. performance enhancements" because one is more inclined to not upgrade rather than proceed with it and possibly risk downtime.
Of course I am saying this blindly, since the submitter did not specify what sort of software this is. Is it a server app? A commercial desktop app? Or is it a game or other entertainment software which is not mission-critical, where downtime can cost thousands to tends of thousands per hour?
Re: (Score:2)
Change logs and proper release notes are very appreciated by administrators and end users.
Administrators yes, end users much less so. The fact that Microsoft used to downplay Linux's stability and security by publishing the "number of bugs fixed" figures for Windows and Linux along side each other (with Windows receiving far fewer fixes and therefore perceived as "better" because people somehow assumed that less fixes == less things to fix) pretty much demonstrates the end-user mindset: I'm pretty sure that a large chunk of end users expect software to be perfect and if you admit that yours isn
Yes, POST change logs (Score:5, Insightful)
It is one of the major criteria I look for in good software --- open communication from the developers about updates, and changes; active recent update history.
Some of the most successful software companies such as Microsoft and VMware post detailed released notes that show bug fixes and improvements.
Detailed changelogs are even better.
If you are concerned about ridicule from a competitor -- you can probably point out the competitor hides their flaws by not posting detailed change logs.
Another thing you can do that's less recommended -- is put the changelogs behind a click-through agreement. Require site visitors register to review them.
Keep in mind it's not just customers that necessarily want to see documentation, release notes, and changelogs.
When I am considering buying a software product I want, EXPECT, and demand to see on the product vendor's website: (1) Pricing, (2) Release notes, (3) Documentation, (4) Change logs, and (5) A trial version download, before I even talk to a salesperson.
These are signs of a healthy well-marketed product, that will be around for years to come. If any of these are missing -- warning flags, or alarm bells are going off.
If the software doesn't have readily accessible documentation, or notes on bugs --- does anyone use this software in the real world?? Is the documentation crap??; If I buy this product -- is it going to be a complex pile - have spending hours upon hours on the phone with their support, working out bugs at every corner just to get the product up and running with basic functionality?
Will I need to make a phone call, to blow my nose with this software?
Re: (Score:2)
+1000 to all of the above.
Re: (Score:2)
Run away...now. (Score:2, Insightful)
This is a boner move by your company. I've seen it happen before, and it's usually a sign of a failing company that fears reality.
Perhaps there was a recent management change? If yes, this is a sign that you've got a cowboy coming in with guns a-blazing and thinks he knows how to run a software shop... GTFO, while the gettin's good.
Re: (Score:2)
This is, for the coder in this situation, also damned good advice. GTFO soonest if you don't want to be chained to the oars in a sinking ship.
depends, but not most important thing (Score:3)
The key is to make sure that each release is an improvement over the previous release. If you do that, your customers will be happy, and won't worry much, as you build trust and confidence over time. In your situation, if a particular customer requests the change logs, I would give them, but a general release is not important.
The real problems come when your releases break things. After an especially bad release, your customers might not be willing to upgrade for two or three years (see: Windows Vista). Make sure each release is better than the previous. That is crucial.
Competition (Score:2)
Does it have to be all or nothing?
Our software supports the hardware so we don't feel any palpable, fierce competition since we always lag the hardware improvements and those get top billing. Our users are interested in knowing the changes that are meaningful to them.
Since I use our change logs to significantly build our "brochure" touting reasons to upgrade, maybe you all can pare down change logs to the "best of the 1000" to say "20"... a list most can bother to go through.
Hiding Something? (Score:1)
I have 2 vendors that my company works for that drive me nuts with the lack of change logs. One posts change logs once a year or so, but has a dozen or so versions released annually. A call to tech support usually confirms that the changes don't affect us and aren't security related, but it's a pain to ask every time. The other fixes and changes a bunch of things with every release (and always breaks a few features that have worked for years...), but only documents a few trivial fixes & enhancements
Most of this info is likely irrelevant... (Score:1)
It is certainly useful to the person who filed bug 1234 to know that bug 1234 was closed in release number 5.7.
But... is the rest of the info in your issue tracking system formatted in any way that will be useful to a customer to read? At many of the places I've worked, we get issues with titles like "page formatted wrong, see attached screenshot". That is a pretty useless thing to automatically cut and paste into your spreadsheet. And severity reflects your internal judgement of severity, which may or
why not? (Score:1)
What reasons are there to NOT put them in?
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.
This is going to happen no matter what you do. If the competition is going to slander you, they will one way or another.
Another question is: Should I have facebook/twitter for my company, if the competetion can use it to slander us?
The answer is: Even if they try to, if you keep vocal on these feeds and try to solve all the grievences that arise, people will see that you give good support - even to trolls - and the competetion will look like trolls when they
Re: (Score:2)
What reasons are there to NOT put them in?
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.
This is going to happen no matter what you do. If the competition is going to slander you, they will one way or another.
Another question is: Should I have facebook/twitter for my company, if the competetion [sic] can use it to slander us?
Better yet, why produce software at all, if people are just going to ridicule and criticise it?
I'm writing this in the hope that you point your management to this discussion and they realise what an incredibly childish move it would be to start hiding information just because people might talk about it. As a CTO, may I say the following: If you don't produce a changelog, and your company isn't one of about three or four whom I'm forced to live with on their terms, you're not getting through my front door. N
Tactful changelogs (Score:1)
what's new, don't need 1000, positive phrasing (Score:2)
Since someone is worried about it, entries could be listed as "improved metafile handling" rather than "fixed horribly broken metafile handling". One could even institute a convention that all commits messages indicate the type of change by starting with the either "New Feature:" or "Improvement". Show the complainer a list of 200 new features and 500 improvements and they may see it's value to customers.
Barring that, as a customer I don't really NEED 1,000 entries. I might very well ask "what's new in th
Re: (Score:2)
Barring that, as a customer I don't really NEED 1,000 entries. I might very well ask "what's new in this version?", though. Mark the 50 most significant ones and pull those for the changelog.
I don't think anyone is expecting to browse through 1000 entries, but if you are affected by a specific bug that you've reported, you might want to do a search on the changelog to see if that bug has been addressed. However, in this situation an open bug tracking system would be more useful so that the customer would get an automatic notification about their bug being fixed.
agreed. If 1000, separate whatsnew. my kernel fix (Score:2)
Absolutely. I ran into a kernel bug, which I helped fix. Now when installing a distro kernel I can check the changelog for my name to see if the bug that effects me is fixed in that kernel. I've done the same with firmware updates, like checking a RAID card firmware to see that it had a RAID 5 performance fix that effects me. For those things, a complete changelog is good.
For the main software I work on, the users normally want to know about the top 2 - 4 biggest changes.
Re: (Score:2)
Since it is a document that will be seen and read by your customers, competitors, and (depending on the market you are in) regulators, you DO NOT assign that kind of a task to a drone. You give it to someone who has technical expertise and the ability to write coherently. Barring that, you give it to a senior developer or systems engineer, who has ultimate technical responsibility for it anyway, and ought to have the best understanding
Fewer than 1000 (Score:4, Insightful)
Some OSS bug trackers have a 'relnote' field where people are to enter a release note if the owner feels it's something that ought to be communicated to the user.
As a user, don't bother me with stuff that will never effect me (did you refactor a class? - great, but I don't need to know about it) or I won't need to look up (did you fix a CVE or a spelling mistake?) but do let me know about changes that will affect my workflow, will offer me an improved way of doing something, or should cause me to go revisit results I've generated in the past (i.e. you had a bug).
Externally meaningful changes (Score:3, Insightful)
My employer produces a compiler tool chain for its products. Its release notes contain two major things:
1. A list of major customer visible changes.
2. A list of defects fixed
The first represents our internal development efforts. It's written in terms of the actual features, how they affect our users, and how the users ought to use them. They are not written in terms of the series of commits that made the features happen. That would just be pointless.
The second represents the defects fixed in this (and recent) releases, as pulled from the bug tracking system. If a customer filed a bug and we fixed that bug, that bug number and a brief description of the bug are in the release notes. Again, this is not tied to a commit stream that addressed the bug, but rather to defect reports that were closed by the release. Most of these defects come from external customers, but not all.
What's not in there? All the internal churn that got us from point A to point B. We distill it down to what the externally meaningful changes are.
Disclaimer: I am not on the team that produces the tool chain I described. I'm just a happy, internal customer of said tool-chain.
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: (Score:3)
Your compliance process is wildly optimistic.
Even if you had full source code and the change sets you wouldn't be able to guarantee no breaking changes. Either something is mission critical in which case it needs to be re-certified or it's not and it probably doesn't.
Re: (Score:2)
I'm fortunately on the coding side these days so I don't have to re-certify all that much anymore, but that also gives me a certain amount of perspective on the impact of change. Even assuming that the information in the issue tracker is complete, which it almost certainly isn't, you're just fooling yourself. The folks who wrote the code don't really understand all the implications of the changes they made and the details in the issue tracker aren't anywhere close. The only thing a change log will ever do i
Email it, don't post it (Score:1)
If you have enterprise customers, then make the changelog available under NDA. Or just email it to key customers that ask, so that prospective customers never see it.
My opinion (Score:1)
I have spent 15+ years in IT buying, selling, and using all manner of hardware and software. When a vendor changes something, I want to know. It's the easiest way to quickly see if some weird problem you are seeing can be corrected by installing an update.
Summarize (Score:5, Insightful)
Re: (Score:1)
I agree with this assessment; although it can somewhat depend on who your customers are and the volume of changes being made, you generally don't need to report every minor change.
I work for fairly large software company (6000+ employees) and we have a staff of several hundred that does all the technical writing from guide updates to major version release notes to patch release notes, as well as handling the writing of issues that are considered reportable to customers due to severity of the
Re: (Score:2)
I wish programs like Irfanview would do this (still waiting for full 32 bit PNG support on that one).
Have fun with it (Score:2)
Some company like to have put a lot of detail into the update notes even stuff like added this next to useless thing (default off) with a list of why it's next to useless and say it's not recommended to trun on.
And this was part of a bigger update.
Also some of updates due have stuff like fixed crash that some times happens when you do X.
On Admitting to Screwups (Score:2)
The OP asks "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?"
Do any such references exist? I don't know of any.
However, I can attest to having watched one vendor who screwed up multiple times [not a software project] in some pretty major ways, and even though we gnashed our teeeth and wrung our hands, the up-fornt honesty of this vendor to admitting to mistakes (which were ultimately fixed)
Re: (Score:2)
The OP asks "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?"
Well he may have asked for that, but I wager he knows better than to expect Slashdot to do his google work for him.
Instead, he gets a multitude of opinions, which, for someone too lazy to google, is all they deserve.
There are bugs in software. Everyone knows that.
All people want to know is that the big issues are fixed. New functionality is added, or old functionality is made easier to use.
Nobody cares about spelling errors corrected.
That kind of stuff is used to justify your job to your boss (found 17 cl
Trust. (Score:2)
Trust.
It's earned from open communication, then living up to your word. No disclosure, no trust, no investment.
As an employee, my next question would be, if they aren't communicating with their most valuable assets (customers), what aren't they communicating with their next most valuable assets (staff)?
Re: (Score:2)
Trust my ass...
Sounds more like burying them in useless information to justify your high price of maintenance contracts.
People see through this snow job very quickly.
People want summary information, not line by line code change logs.
Include at least some comments in release notes (Score:2)
When I've had to support an OS or application I've generally found it helpful for the release notes for an update to contain at least a summary of bug fixes since the last release as a minimum. That is assuming that the comments are detailed enough to be helpful. I don't necessarily need to see them all, but at least the major issues. That can help you decide if you need it to fix issues you are seeing, or if it could effect you. If your software has different collections of bundles of patches, such as
Re: (Score:2)
The lack of change logs is why I never update the firmware on my Blu-Ray players unless something is obviously broken, and even then, only if I can find anecdotal evidence to suggest that the update will fix that problem. I've had way, way too many theoretically minor updates that break things in horrible ways, so unless an update adds some major feature that I care about, I try to avoid updating software unless A. I'm aware that it is broken in a way that affects me, and B. I have reason to believe that
Re: (Score:2)
The risk or breakage is why a non-production testing environment is our friend. Kind of hard to do with a single piece of equipment though.
Re: (Score:2)
. Kind of hard to do with a single piece of equipment though.
The poster you are responding to spoke of blue-ray players in the plural. No risk of a single piece of equipment failing here.
Apparently being without a movie playing for more than 10 seconds is a very frightening thing. He needs multiple players
so that he has no single point of failure.
Re: (Score:2)
. Kind of hard to do with a single piece of equipment though.
The poster you are responding to spoke of blue-ray players in the plural. No risk of a single piece of equipment failing here. Apparently being without a movie playing for more than 10 seconds is a very frightening thing. He needs multiple players so that he has no single point of failure.
Umm... different rooms?
Simple high-level changelog (Score:2)
I like to give my users a fairly high level changelog when putting out an update to something I've been working on. Usually its to call attention to new features or important bug fixes. However, I don't go into too much detail, lest I overwhelm or confuse them. Of course I'm also working on something used by average people, not IT admins.
Also, many of the changes tend to be things never directly visible to the user. These things include bugs fixed in core parts of the app the user is only vaguely aware
disqualifying (Score:2)
the alternative is vastly longer deployment testing, since instead of testing what has changed and things related to it, you are essentially doing a ground up test of every single function used every way
Wrong question: The answer is: don't publish crap (Score:2)
The change log is a product. It needs to be reviewed, readable to the target customers, and compliant to any necessary contractual, legal, or regulatory disclosures with the appropriate disclaimers. It should not reveal any trade secrets, third party confidential information, violate any vendor NDAs, have any unprofessional remarks about the customers, etc.
It sounds like the problem is you're putting out crap change logs using an automated system to copy things from the issue management system. Do you ha
Two reasons not to publish raw logs like this... (Score:2)
Two reasons not to publish raw logs like this... (1) Security vulnerabilities in previous versions, unless you guarantee all your customers have updated, and your release notes follow days after a release to give them a chance to avoid being zero-dayed, and (2) Telegraphing new product direction by either the comments themselves, or in such a way that the changes in aggregate allow it to be inferred.
Either of these things will give customers the opportunity to bitch loudly, and even if you have 10,000 custo
Two change logs (Score:2)
The other is the 'enhancements only changelog' - or what we colloquially refer to as 'the readme'. It only contains feature enhancements or significant bug fixes.
Re: (Score:1)
Stability through obscurity (Score:2)
We should call this practice stability through oscurity.
Always... (Score:2)
Please. if there is a piece of software that I am using, the only reason that I *want* the changelogs are to see if it is worth upgrading and risking other bugs in order to fix the issue I'm stuck with. If there's software that I don't feel a horrendous burden from using it; I'd still like to know what has changed and why I should grab the newest version vs "misc bug fixes".
I have used change logs before (Score:2)
I worked in a large financial services company in Switzerland. We were one of the most intense users of a particular risk & control application. We understood each corner of this application and with each new release we analysed each change in detail. This was necessary to weigh-up the value of upgrading or not, or timing the upgrade appropriately. Some seemingly insignificant change could be a show-stopper for our users.
sniff sniff.. I smell a lawyer (Score:2)
The main reasons for pulling the change logs was the fear of putting the software in a bad light ...
A lawyer got to them and told them they were exposing themselves to liability. Simple.
Changelogs are helpful, but not complete (Score:2)
This is an ongoing problem for my work. People who refuse to write changelogs often say "read the code, becuase they documentation can be wrong". What I've found is that if their documentation is that wrong, their code is usually even worse. Just reading what the code does will force you to replicate fundamental errors, to preserve unstated API's. In such cases, the change logs or revision history are invaluable, to expose why particular features were altered and when and by _whom_.
If software hs good git l
Depending on your target market.. (Score:2)
I'm a developer support engineer for a company that sells several SDKs - It is absolutely invaluable tor our customers (and ourselves) to be able to see the change logs as they're depending on our product to work in certain ways and could be interacting with dozens of systems/components.
I can't tell you how many times I've found that a claimed bug in our product was actually an issue in Weblogic or Websphere or Tomcat, etc.. that was corrected in a given fix (sadly, its often a case of customers coming to u
mis-read (Score:2)
Oh. I thought we were asking Slashdot to publish change-logs.
Never mind.
How this is usually handled in my experience (Score:2)
The issue management system usually includes two fields and one check box. One internal text field that includes information about the issue in great detail aimed for the core developers, and another text fields which includes simplified information about the issue targeted for the end user or management, and then a check box which specifies if this issue should be publicly visible. Usually an issue has both fields filled out and the check box checked, but if an issue is set as private it's usually because
I've had experience with this, actually... (Score:2)
Re: (Score:2)
When I first started working in IT, back in my early software days (as a tech writer),
Apparently "early software days" means "before invention of the paragraph." ;)
A twitter feed of changes. (Score:2)
Some people think we're crazy, but on the game "Card Hunter [cardhunter.com]," we publish all of our check-in messages on Twitter [twitter.com].
Here are some of the benefits:
Change-logs are strictly for internal use! (Score:2)
Re: (Score:2)
Re: (Score:2)
Uh, reading is fundamental. OP isn't suggesting anything, it's cowardly management that puts covering their own asses over providing a quality product.