Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

raymii.org

Post reply on HN
Print view View original

101–110 of 127 posts

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#101

Post by dasil003 »

Contrarian viewpoint:

I'm very passionate about this idea for open source software, especially things like ruby gems or npm packages that I might use as a dependency, but for some reason I can't muster the indignation to care about this for apps. Maybe it's because I care primarily that the app works and the latest version is stable. I'm generally not going in and considering upgrades to apps strategically, and even if I did I have no ability to see the previous changelogs let alone install those versions. If for some reason I want to avoid an upgrade now I'm living on borrowed time and need to start thinking about a replacement or carefully curate my backups so as not to lose access. Sure in a perfect world it would be nice to have perfect changelogs, but it's so far down the list of things I want out my apps that I place zero value on it.

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#102

Post by [deleted] »

pjc50 wrote: post #75
goldenManatee wrote: post #19

Earlier quoted context omitted.

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?

[deleted]

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#103

Post by gregmac »

goldenManatee wrote: post #19
CJefferson wrote: post #6

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…

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’…

The take-away from this is if a vendor doesn't provide a good changelog, it's fair to assume they're trying to cover up incompetence (or some other shortcoming).

With good automated testing, a bug recurring should be extremely rare. A piece of the software that constantly has bugs is a sign there's high technical debt that needs to be addressed. New features consistently not working could be a sign of a problem in the team/org itself (not the right people, enough people, or enough time allocated).

Even with all the best practices, big faults will make it through sometimes -- that's just the nature of most software dev. I think the best way to handle them is be transparent, but also be specific. "Fix bug where entire database can be corrupted" will cause you a lot of grief (rightfully so). Something like "Fix critical data corruption bug when saving a record containing specific trailing unicode characters on systems with libzip 1.3.3 or earlier installed" is much better and helps reinforce that:

1. You have thoroughly investigated the problem

2. The scope of problem is limited, and doesn't affect all customers (even though it could be most)

3. It's understandable how such a bad bug could happen and why testing didn't catch it

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#104

Post by megous »

gregmac wrote: post #60
CJefferson wrote: post #6

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 think the key is describing the user-facing effects and impact. This means knowing your users (are they developers, IT or highly technical? Do they automatically or manually update quickly, or do they take time to evaluate before rolling out updates?). It's a way to convey continuing value to users and convince them it's worthwhile to keep paying, and get motivated to get the update. I'd try to change what you wrot…

For closed source systems detailed changelog is very nice. "Fixed USB reset issues" is close to useless, when you try the new firmware and it still exhibits USB reset issues. More detail the better. And describing the actual changes ("increased XYZ timeout on USB resume") instead of symptoms they tried to address ("we fixed the USB reset" - not) is actually much better.

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#106

Post by mlyle »

gregmac wrote: post #60
CJefferson wrote: post #6

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 think the key is describing the user-facing effects and impact. This means knowing your users (are they developers, IT or highly technical? Do they automatically or manually update quickly, or do they take time to evaluate before rolling out updates?). It's a way to convey continuing value to users and convince them it's worthwhile to keep paying, and get motivated to get the update. I'd try to change what you wrot…

> I'd try to change what you wrote to something like:

I'm used to seeing from well managed projects a paragraph saying that there's new feature A and bugfixes and performance improvements.

And then a detailed change log with big feature A, smaller features B & C, and 10 bug fixes described. Maybe 2-3 performance improvements that are expected to only -really- help with degenerate cases.

And then, there's a dozen things that aren't considered important enough to be in this list.

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#107

Post by toast0 »

damnyou wrote: post #97
toast0 wrote: post #85

Earlier quoted context omitted.

If you're shipping a mobile app with client side code (so, nearly all of them), there is no good rollout process. You can't ship a quick update with Apple, because review isn't quick. Users who upgraded soon after release will be stuck with something broken until the new version is available. You can usually ship quickly with Google, but users are slow to upgrade, but may have caught your first one, and not get your…

I'm talking about feature flag based rollouts, which don't involve going through Apple or Google.

Hope you didn't mess up your flag system. Or your feature flagged feature doesn't corrupt your locally stored state.

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#108

Post by lmz »

pc86 wrote: post #67
curryst wrote: post #44

Earlier quoted context omitted.

Sure, but most people accept that flaws are inevitable. It's not practical (or profitable) for most industries to produce totally flaw-free software. If you can't stop the flaws, the next best option is to shield yourself from those flaws harming your financial well being.

Having a changelog does not make you more open to lawsuits.

A detailed changelog wouldn't change the facts, but it just provides more free information to potential plaintiffs.

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#109

Post by XCSme »

When I make performance changes I like testing the actual gains on the live server and add them to the changelog, something like: "Improved profile page loading speed by 25%".

For reference: https://docs.usertrack.net/changelog#usertrack-3-3-1-11-dece...

Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

#110

Post by ghayes »

WalterBright wrote: post #100
gregmac wrote: post #60

Earlier quoted context omitted.

I think the key is describing the user-facing effects and impact. This means knowing your users (are they developers, IT or highly technical? Do they automatically or manually update quickly, or do they take time to evaluate before rolling out updates?). It's a way to convey continuing value to users and convince them it's worthwhile to keep paying, and get motivated to get the update. I'd try to change what you wrot…

> Doing this well takes time For us, not that much time, as everything goes through the bug tracker (even enhancements) so it's mostly a copy-pasta job. When I submit a fix for a bug, I'll often edit the subject to accurately reflect what the problem actually turned out to be.

Even less time if devs add these to CHANGELOG.md with each user-facing change so that it’s already compiled for you.
Post reply on HN