11–20 of 127 posts
The 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:…
The 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…
I automate the app deployments for our team and “bugfixes and performance improvements” is the changelog because it’s totally automated on release. Yes the automation could grab something from the commit logs but I’m not confident I’d want to expose some of our commit messages. Also recent versions of iOS have further hidden away the update ui making it very hard to find for most users, so why bother taking the time…
The 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:…
The size of the organisations is not important, as is the size of the team working on the particular feature/app.
Apple is huge, for example, but eg. Logic Pro has great changelogs.
We also see huge apps (with large teams) do better than than small apps (with much smaller teams). It's more about bothering/caring than difficulty.
Although I'll try to resist going on too much of a pro-FOSS rant, the change audit process is much easier for open source projects since you can read not just the changelog entries, but also the corresponding code to verify the claims.
That helps with various things including developer trust - it helps you determine whether a project and authors use test coverage to reproduce bugs and prove their fixes, whether performance improvements are measurable, whether there are risky side-effects to look out for, and so on.
Increasingly I think that these kinds of 'software due diligence' should become part of recommended software engineering workflows, and that makes me wonder whether some of the repetitive aspects can be automated.
A genuinely user-focused, trustworthy app ecosystem would, I think, allow some of these 'change audit' processes to be visible to users so that they can make informed upgrade decisions, and to create a marketplace incentive for upgrades to be reliable.
In an "app store" context, the apps don't serve you; you just generate content/engagement for them. The apps you're looking at don't WANT you to be informed because you might choose not to use them. These notes are just a formality standing in for forced automatic updates. Spotify on Google Play is particularly insulting. They basically tell/shame you that you should just always update without caring about the change…
This is a non-sequitur.
There are all kinds of apps in an "app store" context, and the apps I use serve me very well, thank you. I also don't generate any "content/engagement" for any of them.
Whether apps have good changelogs or not is also not a factor of whether the apps are in an app store or not.
You maybe meant to say "social apps" as opposed to "app store" apps.
The 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…
Deep understanding of a change is really helpful when looking through history or trying to make sense of why this particular line was changed, etc.
The 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…