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

81–90 of 127 posts

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

#81

Post by damnyou »

joepie91_ wrote: post #33
mfDjB wrote: post #5

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

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

No. what it signals is that app releases are decoupled from feature releases. Of course people know when a new and important feature is being released, it's just completely independent of when the app store update goes out.

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

#82

Post by baby »

That was not really interesting, so I'll start a related thread:

- why is performance often favored instead of improving, refactoring, documenting, simplifying, etc. And how can we change that?

- why are bug fixes so hard to track? Often developers fix something without marking it as a bug fix. And how can we change that?

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

#83

Post by toast0 »

pc86 wrote: post #66
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 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.…

> 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.

It's precisely because an update might bring more crashes that I'd like to see what changed.

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

#85

Post by toast0 »

damnyou wrote: post #79
0xbadcafebee wrote: post #51

Earlier quoted context omitted.

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.

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 second one for some time.

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

#86

Post by toast0 »

joepie91_ wrote: post #33
mfDjB wrote: post #5

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

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

> there's not a single person in the organization who actually fully knows what is being released.

Sometimes there is, but as siblings point out, it's difficult or not cost effective to distill this information into an app store changelog blurb.

More often (in my opinion), it's the terrifying situation you describe. Nobody know what the heck is going on at an overall level. Which can work surprisingly well, but often means efficiency (network, memory, cpu, disk space) is very hard to come by.

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

#88

Post by mottosso »

This topic and responses to it warms my heart. :) I've made it a habit for my current project to turn changelogs into blog-like material for the end-user. The kind of changelog I would like to see from other software, especially the kind I care about.

For example: https://learn.ragdolldynamics.com/releases/2020.12.01/

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

#90

Post by a1369209993 »

pc86 wrote: post #66
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 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.…

> 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.

Umm, no; if you're a technical user, you know it is likely that update == "more crashes, slower load times and useful features breaking or disappearing entirely", regardless of what the changelog says, because you've observed exactly that happening with eg your webbrowser or image editor.

> "Bugfixes and performance improvements" [(]is a given[)], and [(]helps no one[)].

Well, you're half right.

Post reply on HN