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

121–127 of 127 posts

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

#121

Post by saagarjha »

sirsuki wrote: post #112

The FOSS community still campaigns the idea of Open Sourced software on desktops. Why then is the same not as popular in other platforms like iOS or PWAs? I truly wish I could visit github.com/[my-iOS-ap]/project and contribute or read the geeks' changelog while the app store can have the simplified changelog for non-coders. This is one of the reasons I think https://blink.sh/ is one of the best iOS apps out there.

The big issue is probably that the mobile platforms have significantly different monetization models and incentives. It’s possible to run an open source app, but you’re doing it mostly out of the good of your heart a lot of the time.

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

#122

Post by saagarjha »

Santosh83 wrote: post #27

These are changelogs for end users, not fellow developers. In fact I expect that even these "one line notices" will be dispensed with in future as the concept that any software or device requires an always-on connection to the Internet becomes fully normalised. Apps/devices will simply update and that's that. You won't be given any sort of option or toggle. Does anyone seriously ask the govt NOT to maintain a road or…

You can be annoyed when someone comes by to bulldoze your house to build a hyperspace bypass, though.

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

#123

Post by saagarjha »

alexcroox wrote: post #8

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…

> Also recent versions of iOS have further hidden away the update ui making it very hard to find for most users

Thanks for your contribution to society, Apple Arcade.

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

#124

Post by JimDabell »

Master_Odin wrote: post #118
JimDabell wrote: post #42

Earlier quoted context omitted.

> 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! It’s not the collection of the information that’s difficult, it’s delivering it to the user in an appropriate way when you use phased rollouts with feature flags.…

"Begin rollout of feature " "We are rolling out in to ensure about , and rollback if . You will notice you have when ." If you don't put anything about new features, don't be surprised when users don't use them (because why would they know) or complain what something "breaks" (or just changes on their workflow) because your changelog communicates nothing.

> "Begin rollout of feature " "We are rolling out in to ensure about , and rollback if . You will notice you have when ."

That’s a guaranteed way to get users complaining that they don’t have a new feature that you “promised” that they may never receive. It also isn’t appropriate for multivariate testing and just isn’t going to be understood by most users anyway.

There are way to do this in a decent way, but you have to do it within the application using your own logic. The change log provided by the platform is inadequate.

> If you don't put anything about new features, don't be surprised when users don't use them (because why would they know)

If you need to tell your users about new features in the App Store change log, then you’ve already failed because almost nobody sees it. Users know about new features because either a) it’s obvious when you use the application, or b) you tell them about the new features somewhere they will actually see it, at an appropriate time.

> or complain what something "breaks" (or just changes on their workflow) because your changelog communicates nothing.

A change log does not prevent this. You are attributing a lot of power to the platform change log that it simply does not have.

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

#125

Post by [deleted] »

JimDabell wrote: post #124
Master_Odin wrote: post #118

Earlier quoted context omitted.

"Begin rollout of feature " "We are rolling out in to ensure about , and rollback if . You will notice you have when ." If you don't put anything about new features, don't be surprised when users don't use them (because why would they know) or complain what something "breaks" (or just changes on their workflow) because your changelog communicates nothing.

> "Begin rollout of feature " "We are rolling out in to ensure about , and rollback if . You will notice you have when ." That’s a guaranteed way to get users complaining that they don’t have a new feature that you “promised” that they may never receive. It also isn’t appropriate for multivariate testing and just isn’t going to be understood by most users anyway. There are way to do this in a decent way, but you have…

[deleted]

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

#127

Post by jfengel »

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

Some non-technical users do read change logs, looking for new features. Even if they take every update, the notification of an update pings the hope that there may be something useful or fun. "Bug fixes and performance improvements" means "you need this update but there's nothing you really care about".

So there are least two kinds of updates, those with user-facing features and those without. Currently both come in the same stream. We could come up with a better way of differentiating the two, including not notifying users at all when the boilerplate "fixes and performance improvements" comes on. Just update the app and what the user doesn't know (hopefully) won't hurt 'em.

Post reply on HN