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

21–30 of 127 posts

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

#21

Post by jrootabega »

coldtea wrote: post #17
jrootabega wrote: post #2

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…

> In an "app store" context, the apps don't serve you; you just generate content/engagement for them. 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…

I guess I'm focusing on the ones at the top of the food chain, and the what I think is the predominant relationship in app stores, not necessarily the social ones. Eg the Microsoft ones in the article

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

#22

Post by bauerd »

christophilus wrote: post #18
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 prefer the detail. You could always make the first line: “bug fixes and performance improvements” with details following. Then people who don’t care can ignore the details, but people who do care can get an understanding of what the change is about. 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.

This is about app store changelogs, not commit messages

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

#23

Post by sltkr »

jandeboevrie wrote: post #7
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…

Hehe I'd be happy to read such a changelog

I doubt you would. A large app each would have hundreds of changes like this. It would get pretty boring after the first dozen or so.

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

#24

Post by vbezhenar »

johannes1234321 wrote: post #4

With many apps an issue for changelog writers is that often behavior is tied to feature flags, which can be remotely enabled. Thus a new feature is rolled out in the app but only visible to some testers. Only after a while it's enabled for all users. Thus app release is independent from availability of a feature. That said "Bugfixes and performance improvements" is as useless as it gets ...

I wonder how those features pass Apple review? It's easy to disable those flags to get review passed and enable them later.

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

#25

Post by hashkb »

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

Difficulty of task never excuses doing a lazy job. Especially if you hope people will pay you.

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

#26

Post by altitudinous »

I used to love posting detail about what I change in my apps. But now the text isn't really surfaced - folk have automatic updates turned on, and the text is deep in the app store now.

My changes are mostly technical when I use the "bug fixes and performance improvements" text, but I tend to write more for the app store reviewers to let them know what is going on. I know they read it.

In the end my audience of users are very non technical. I am authentic to them, that is the image that I sell my apps with, and I am good at it. So they just don't care that I've updated library X, or improved error handling somewhere, or I support Apples latest devices now. They do have faith that I am doing the right thing, and they write to me as if they know me, and I like that.

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

#27

Post by Santosh83 »

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 bridge? Such will be the case with software too.

Individual freedoms and privacy have no future in the direction technology and society are going.

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

#28

Post by kingosticks »

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…

I think I'd argue it's not "totally automated" unless skipping the changelog generation step was the intention. In which case no need to justify that with any reasons, that's your (valid) choice to omit some documentation. We used to maintain our "customer-facing" changelog as we merged the associated code but that did create work when trying to release and finding some people had forgotten to provide an entry, which ultimately reduced release frequency. So now we don't include a changelog in the release itself, we create it after the fact and it's more of a "living" document hosted online (having to create another new release just because of dumb mistake in your latest changelog is really annoying). For those that are really interested, they can check the commit logs. For those less interested, they can wait for the online changelog to be written. It's likely they'll only have to wait a few minutes. Obviously the former is easy for open-source projects. I'm not convinced our new way is better yet but I'm willing to wait and see if the release frequency improves.

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

#30

Post by mackey »

coldtea wrote: post #14
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:…

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

Apple has a much more traditional engineering structure and traditional release cadence though. A lot of the "worst offenders" of these types of release notes are structured and work much differently. They release updates 1-2 times a week, sometimes release features weeks after the code has shipped to users, and sometimes in stretched out rollouts.

They say there if there is a will, there is a way, so in a sense I agree that these companies probably could do something about it if they really wanted to, but I also don't think it would be easy, and considering how few people actually look at release notes, I am not sure the investment is worth it.

Post reply on HN