[deleted]
Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
71–80 of 127 posts
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#72This is precisely why I started https://keepachangelog.com/ many years ago. Release convenience shouldn't come at the cost of properly communicating about notable changes for software users (whether developers themselves, or software consumers).
Instinctively, developers reach for automation to solve this problem but this is an editorial problem for most software. Code changes very rarely map to notable changes for your intended audience. Even with rigid system like conventional commits, you can't entirely automate proper human-focused changelogs and release notes.
You're going to have to clean things up and editorialize if you really care for your software users to understand what notable changes are included in a given version release.
If you can't think of any, maybe you're releasing too often. If it's impossible to tell things apart because there are so many changes as another commenter pointed out, I think you have a way bigger problem.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#73when we build a new feature, it's gated by a flag controlled by the server. The app version with the feature is distributed well in advance of the intended rollout. So, we can't even put the new feature in the change log for the update that includes the feature, and the rollout won't be associated with an app update.
All we can really put in the change log is bug fixes, and the circumstances that result in a bug can often be obscure and hard to describe in user-facing terms, so it gets summarized: "bug fixes and performance improvements". And for the play store and the app store, we have to put _something_.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#74The 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…
See Reaper (the audio thing) for the opposite extreme. The changelog lists everything, so sometimes you miss significant new features because they don't make a big deal about it.
https://www.reaper.fm/download.php#whatsnew
They put a whole notation editor in and didn't say anything past the item in the changelog. Most tools like it have a notation editor, but it's a $300 addon instead of a free update to the standard $60 package.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#75The 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’…
Are there ever successful software product quality liability lawsuits?
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#76The 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…
It's important to list what bugs you fixed. You can do fancy things like group your changelogs under headings if you want to make it easier to maintain focus for different audiences. A CAD tool I use, for example, lists every single bug fixed and references a ticket number with each. This is extreme, but much better than the opposite extreme.
It lets me know when I can stop using workarounds, or alert me to landmines I've unknowingly tripped and lets me go back to verify old designs.
Regardless of who the user is, a changelog is supposed to tell you what actually changed. If you're not going to do that, don't bother having one. But if you don't bother writing one, I'm not going to bother updating to the new version. From my (the user's) perspective there's no incentive to do so unless I know what I'm getting. There could be anything in there, so I'll stick to the devil I know.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#77The D compiler have had a great changelog since years and it has made a difference to popularize what went into an update. Each major change comes with examples, and it's great content.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#78The 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 think the author of the article brings up a good point regarding this, though. If you're a non-technical user, you're not going to read it at all. You might update, you might not, but you're not going to look through the list of changes. If you're a technical user, you know it's unlikely that update == "more crashes and slower load times" so saying the opposite isn't helpful, and a list of things might be helpful.…
Even when I'm in group 2 and don't want to read every update, I'm reassured by the fact that users in group 1 can find relevant information. I also sometimes move from group 2 to group 1 when I need to track down what version introduced something that's just now causing me problems. :)
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#79The 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:…
Which is a good indication that the organization actually has no idea what the heck is going into the update.
Assuming there are good rollout and incident review processes in place, this isn't much of a problem in practice.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#80The 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 article says at the end: "You see? Not that hard right?". It is that hard in bigger organisations. 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 t…
Logic Pro doesn't have server-side feature flags.