Forgot your password?
typodupeerror
Software

Ask Slashdot: To Publish Change Logs Or Not? 162

Posted by Soulskill
from the fixed-a-bug-with-arcane-missiles dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: To Publish Change Logs Or Not?

Comments Filter:
  • by phantomfive (622387) on Tuesday December 10, 2013 @11:09PM (#45657385) Journal
    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.
    • by istartedi (132515) on Wednesday December 11, 2013 @12:16AM (#45657787) Journal

      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.

    • by icebike (68054)

      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

    • by rve (4436) on Wednesday December 11, 2013 @01:52AM (#45658211)

      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.

      • 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

      • But, but! My boss buys me coffe to drink twice a day. Should I refuse it and pretend to write a changelog instead, while reading slashdot? I'm now worried he'll think I'm a slacker. (Hey boss, if you're reading this I'm stumped on the spelling of funtionallity. Does it take on k or two?)
      • by bwcbwc (601780) on Wednesday December 11, 2013 @06:50AM (#45659037)

        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.

      • by AmiMoJo (196126) *

        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

  • Nope (Score:2, Informative)

    by Anonymous Coward

    I won't install an update without a change log.

  • by Anonymous Coward

    *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)

    by Marsell (16980) on Tuesday December 10, 2013 @11:14PM (#45657453) Homepage

    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.

    • by s.petry (762400) on Wednesday December 11, 2013 @12:08AM (#45657751)

      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.

      • by bored (40072) on Wednesday December 11, 2013 @01:05AM (#45658009)

        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.

        • 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.

          You might be interested in Fossil [fossil-scm.org] then.

        • by s.petry (762400)

          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.

      • by bwcbwc (601780) on Wednesday December 11, 2013 @06:53AM (#45659043)

        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,.

        • by s.petry (762400)

          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.

    • by Anrego (830717) * on Wednesday December 11, 2013 @12:22AM (#45657819)

      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..).

      • by Cenan (1892902) on Wednesday December 11, 2013 @04:31AM (#45658687)

        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.

        • by Anrego (830717) *

          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.

          • by Cenan (1892902)

            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.

    • by PaddyM (45763)

      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

    • 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

    • by c0lo (1497653)

      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

    • 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)

    by kimvette (919543) on Tuesday December 10, 2013 @11:16PM (#45657461) Homepage Journal

    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?

    • 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

  • by mysidia (191772) on Tuesday December 10, 2013 @11:18PM (#45657475)

    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?

    • +1000 to all of the above.

    • Changelog is the best way for user to find out about new features and bugfixes. If they don't know about them they don't use new features and don't get rid of their obsolete bug workarounds. If you don't post changelog you make entire program less useful and the work that went into making the update is partly wasted.
  • Run away...now. (Score:2, Insightful)

    by Anonymous Coward

    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.

    • 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.

  • by phantomfive (622387) on Tuesday December 10, 2013 @11:21PM (#45657495) Journal
    Different customers are going to feel differently, but in my experience doing releases, a different thing matters more.

    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.
  • 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.

  • by Anonymous Coward

    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

  • by Anonymous Coward

    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

  • by Anonymous Coward

    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

    • by grcumb (781340)

      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

  • I'm of the impression that if something was a problem but is fixed, the changelog pointing out the potentially "ridiculous" problem should be more of a badge of pride for resolving it. That said, there's no reason everything has to be included in a changelog, and even fixes that are included can be carefully stated so as to work around anything capable of being ridiculed or revealing additional holes in security or quality.
  • 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

    • 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.

      • 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.

  • Fewer than 1000 (Score:4, Insightful)

    by bill_mcgonigle (4333) * on Tuesday December 10, 2013 @11:42PM (#45657607) Homepage Journal

    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).

  • by Mr Z (6791) on Tuesday December 10, 2013 @11:45PM (#45657625) Homepage Journal

    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.

  • by Todd Knarr (15451) on Tuesday December 10, 2013 @11:48PM (#45657637) Homepage

    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.

    • by Eskarel (565631)

      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.

  • 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.

  • by Anonymous Coward

    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)

    by saleenS281 (859657) on Tuesday December 10, 2013 @11:56PM (#45657687) Homepage
    While it will take more work, posting EVERY change is completely unnecessary, and oftentimes unhelpful. The publicly released changelog should include human-readable summary's of bugfixes and new features. If a customer asks for more details about a bugfix, feel free to give them the unedited version as you see fit. A changelog should NOT be a git history. Information overload is oftentimes less helpful than nothing at all because someone may spend hours to days sifting through it all only to figure out what they were looking for isn't even there.
    • by Anonymous Coward

      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

    • by Twinbee (767046)
      Well said. When I write the history and bug fixes for my OpalCalc [skytopia.com] program, I make sure to put the most important changes at the top of each release, and sometimes in bold/yellow to emphasize how big the change is.

      I wish programs like Irfanview would do this (still waiting for full 32 bit PNG support on that one).
  • 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.

  • 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)

    • by icebike (68054)

      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.

    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)?

    • by icebike (68054)

      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.

  • 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

    • by dgatwood (11270)

      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

      • 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.

        • by icebike (68054)

          . 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.

          • by dgatwood (11270)

            . 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?

  • 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

  • not posting change logs is going to all but disqualify you from consideration from many shops, unless your offering is the only one that can work, or none of your competitors offer change logs. how can anyone manage a deployment to hundreds+ or thousands+ of users without knowing what is going to change.

    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
  • 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... (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

  • We encountered the same problem, so a few years ago, we started running two changelogs. One of them is the full changelog, with every ridiculously miniscule change listed. This is made available to customers, but not promoted to them.

    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.
    • by karpis (1375295)
      We came to this compromise also. We have two logs: internal and external. Every change is included into detailed internal log which is very useful for programmers and support team and customers get softened (theres no need to panic) log. Of course if our client found bug and interested into details we would provide those.
  • 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.

    We should call this practice stability through oscurity.

  • 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 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.

  • 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.

  • 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

  • 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

  • Oh. I thought we were asking Slashdot to publish change-logs.

    Never mind.

  • 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

  • When I first started working in IT, back in my early software days (as a tech writer), we did assemble a release report out of the defect tracking system, but then groomed it so that the descriptions were meaningful, and they communicated what the customer would actually see a a change. So many software changes don't leave much of a trace or evidence of a change at all that at some point you need to focus on the things you fixed/enhanced that could be appreciated. Occasionally, when there was a meaningful g
    • by mcmonkey (96054)

      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." ;)

  • 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:

    • 1.) We have taken up the discipline of writing check-in messages that are easy to digest.
    • 2.) Players have an opportunity to get excited about what we are doing before it is released, but after we have done the work.
    • 3.) Players can see that it's a living project -- that we are actively improving the game.
    • 4.) Players can see that bugs are being fixed -- that we care.
  • Change-logs should be strictly for internal use! 1) Log entries will contain technical shorthand that is meaningless to novices. 2) Opening these logs up exposes the company to all kinds of liability. 3) Do you think most people want to wade through mostly trivial and redundant entries? The proper forum to introduce meaningful new features to the public is in a blog. It goes without saying that this blog should be actively maintained and have at least one person whose sole job is maintaining it and filter
    • Sorry to reply to myself, but I have one thing to add: the person who maintains this blog should most certainly have a technical writing background.

My problem lies in reconciling my gross habits with my net income. -- Errol Flynn Any man who has $10,000 left when he dies is a failure. -- Errol Flynn

Working...