Because you aren't meant to know what the changes are, just consume.
Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
31–40 of 127 posts
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#32With many apps an issue for changelog writers is that often behavior is tied to feature flags, which can be remotely enabled. Thus a new feature is rolled out in the app but only visible to some testers. Only after a while it's enabled for all users. Thus app release is independent from availability of a feature. That said "Bugfixes and performance improvements" is as useless as it gets ...
I wonder how those features pass Apple review? It's easy to disable those flags to get review passed and enable them later.
I'm pretty sure that's what Fortnite did right before they got kicked out of the App Store.
Before my company implemented IAP in a few of our apps we did the same thing, but decided the risk was too great. Getting rejected is one thing, but getting your account terminated is obviously a much bigger deal.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#33The reason these bigger apps just put "Bugfixes" and "Performance Improvements" in their changelog is because when you have many teams contributing to the software not only through actual code editing but also feature flagging what features go out on what release, rollback policies etc this becomes a nightmare to fill in. Doubly so when different users are receiving different experiences. The article says at the end:…
> when you have many teams contributing to the software not only through actual code editing but also feature flagging what features go out on what release, rollback policies etc this becomes a nightmare to fill in.
This is a terrifying sentence to me, because what it implies but doesn't say outright, is that there's not a single person in the organization who actually fully knows what is being released. If there were, then they should already have this information!
Honestly, if you don't have a release manager with a 30,000 foot view of the operation, you probably have bigger organizational problems than "it's hard to know what to fill in on the app store's release notes".
This is how retrospectives on supply chain attacks start, basically.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#34Yeah, it is nice to know what the actual changes are, rather than a vague 'fixes were made' statement. Nintendo's update logs for games have to be some of the most hilariously vague in that regard, with many of the updates being just:
> Several issues have been fixed to improve gameplay experience.
But at the same time I guess I can see why companies and project creators don't go into more detail. Maybe the actual bugs fixed were so weirdly technical that most users wouldn't understand them at all, or care (if the user hovers over this button for 1/300th for a second, there's a 0.0001% chance their next message might not save properly). Maybe they (perhaps sadly) don't remember what exact things they fixed, since they fixed so many bugs.
Either way some more detail would be nice for those that do care about this stuff.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#35Yeah, it is nice to know what the actual changes are, rather than a vague 'fixes were made' statement. Nintendo's update logs for games have to be some of the most hilariously vague in that regard, with many of the updates being just: > Several issues have been fixed to improve gameplay experience. But at the same time I guess I can see why companies and project creators don't go into more detail. Maybe the actual bu…
> Nintendo's update logs for games have to be some of the most hilariously vague in that regard
On the flip-side, the changelogs for Super Smash Bros Ultimate and Splatoon 2 are some of the best I've ever seen.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#36Translateing : #$(ticketId) Resolved by $(implementation details) into something the end user understands IS HARD!
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#37The problem is often the "bugfixes and performance improvements" are a list of 60 things, and for almost all users "there are less crashes and it is faster" is all they would want to know. How many users want to read (OK, possibly people here) "On some versions of glibc, the 32-bit specialisation of memcpy which used SSE2 instructions had a bug when the memory being copied crossed the 2GB boundary, so in that case we…
There’s also a mitigating liability aspect to this. If you start providing minutiae detail, you may start revealing pretty big faults that have escaped to prod. People question the safety of your product and now you’re open to lawsuit or at least micromanaged by some unforgiving end-customers. To cope, you start to not fix certain problems so you won’t have to report the bugs or you start lying what the bugs were. I’…
Aren't the flaws the sources of the liabilities?
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#38> If that is all you're going to put there, then just leave it blank.
Well, I would love to. Unfortunately neither Play Store nor App Store allow you to do that... so "bug fixes and performance improvements" it is, 99% of the time.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#39I also have automatic updates off and I really like checking changelogs to know what new things I can play with.
And I don't mind reading 'bugfixes and performance improvements' ... but only if that's really what the new version is about. I like changelogs, but even for me a 'we fixed an issue where if you enter a 1025 characters text into the title textbox and press back twice while rotating the phone the app closes' is probably too much, but if you added a new option to increase the text size please say it, I don't want to check all the settings screens each time each app updates, and more often than not someone tells you 'hey, aren't you using this option?' No, no I wasn't, because no one told me.
Are you a big company and you have automated updates? Why not have an automated checklist of changes too? I'm sure you have a 'roadmap list', so use it.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#40The problem is often the "bugfixes and performance improvements" are a list of 60 things, and for almost all users "there are less crashes and it is faster" is all they would want to know. How many users want to read (OK, possibly people here) "On some versions of glibc, the 32-bit specialisation of memcpy which used SSE2 instructions had a bug when the memory being copied crossed the 2GB boundary, so in that case we…
Doesn't have to be coverage of every minute detail down to the implementation, but a rough outline of at least the most significant changes seems like a good middle ground. On several occasions I've revisited a feature (or even an entire application) upon seeing that an issue I've had has been addressed in the changelog.