1. 17
  1.  

  2. 3

    I feel rather strongly that this is intentional obfuscation. Many companies want to share as little information as possible with users. In part this is because transparency and truthfulness become weaponized by competitors. But also because companies view customers as adversaries, or at least as frenemies, when their changes break your workflow.

    1. 3

      That and a huge number of app devs just lack either the skill or the ambition to write decent change notes. I complained about uninformative app changelogs years ago on reddit and got a pile of responses telling me that I was an idiot, because users don’t want to read a bunch of stuff about how you refactored the WindowStrategyFactoryObserver. When I answered that of course you don’t write about your code changes, you write about what they actually mean for users, I got two kinds of responses:

      1. “Coming up with a user-centric list of improvements sounds like a lot of work, I’m not doing that!” (If you don’t already have bug reports, user stories, or some kind of thing that captures users’ problems and desires, that you can cross-reference your finished work to, how are you prioritizing work in the first place?)
      2. “What about when a release doesn’t have user-visible changes?” (Okay, so this version has no significant changes from the user POV but it was important for you to push a release anyway? If that happens more than once in a blue moon then I think your app is doing something shady. And no, I don’t think something like an API upgrade falls under this category — “updated the Frobozz API to v3 so that Splorch Effects don’t stop working in March 2021” addresses a user concern [people want Splorch Effects to work], and is potentially useful to someone looking through the release notes in April wondering why Splorch Effects are broken and whether an upgrade might fix them.)
      1. 3

        And you’re almost guaranteed that those same devs have commit histories that are a complete and utter mess.

    2. 2

      I also used to be a person who would update apps manually, just so I could read the changes and know what new to expect from each update. I don’t do that anymore, however, due to this exact problem. There’s just no point in doing it any more.

      The worst part is that I’ve seen this pattern reused in changelogs on open source projects as well. I can’t remember which one it was right now, otherwise I would have provided a link.

      1. 2

        I always assumed this was because the app stores require non-blank release notes but the companies assume (possibly correctly) that the notes are only read by a vanishingly small percentage of their user base.

        It annoys the heck out of me too but I can on some level sort of understand a product team reaching the decision that it’s not worth the cost of having a human write a summary of what changed in each release.

        1. 1

          Yeah, I don’t get why this is so prevalent among mobile apps especially. I don’t even expect a full detailed list, but this is just pointless filling in of forms for the sake of it.

          Probleemoplossingen en prestatievereringen is a pretty awkward translation IMO; it’s almost like the translator was forbidden to use more than two words and was forced to invent a new one.

          1. 1

            Regarding the translation comment, I suspect it’s auto translated. Looking at your site -> resume, you speak dutch, cool!