Changelogs are really difficult to do properly. The concept of a "release" is fuzzy in a world of continuous deployment, and feature flags and experiments mean that different customers are seeing different features. The release of the client that can support the feature is often very divorced from the enablement of the feature. This is not a new phenomenon and has been something we struggled with way back in 2013 in my first SaaS job. Even if you do have a defined set of changes, the way modern software releases work means that the changelog is often the only reason to collect and document those all in one place, and not always a sufficiently compelling one to justify gathering and coordinating this information across teams in a large organization.

Anyway, time to go go see if Claude's done drafting that changelog I asked it to do...

▲

tdy_err 2 days ago | parent | next [-]

It may be difficulty to do properly but then we shouldn’t throw our hands up and do nothing instead? Surely we can come up with a better practice better then filling the release form’s required details field with “Bug Fixes and performance Improvements” every single release? Here’s a quick skimmed list of iOS apps I see doing this currently: Carvana Cash App IMDB Kick Turo Twitch Instagram Prime Video I’ll stop now as it’s nearly every app. Even Apple’s own apps do this— directly from the company who controls the UI of the app store and the developer experience of filling out the form with placeholder messages

▲

phoenixy1 2 days ago | parent [-]

It depends. For stuff like npm packages, where the downstream consumers have to make a conscious decision about whether to adopt the update or not, I absolutely think it's worth getting it right, especially for major version bumps. I myself am the user of an open source code gen tool that does not have comprehensive changelogs, and it makes me want to tear my hair out because we can never be confident when upgrading whether or not we're going to end up with changes that will break our workflows or our customers' workflows.

But for consumer apps, honestly, maybe not? Even at companies that do good consumer changelogs, they're generally considered marketing content. Other posters in this thread made the points that most people updating consumer apps are not even going to see the changelog message, and that app stores have effectively punished companies for providing detailed changelogs by holding app store releases over them.

And given that for larger companies so many of them are actually controlling their feature releases on the backend and not on the client side (you might add the capability for a feature on the client months before you actually set the rollout to 100%), trying to convey those updates in the client-side changelog can be hard to do in a way that consumers will understand and can often generate a lot of confusion and support tickets. After all, we don't expect a changelog entry every time a website updates, and I feel like every day mobile and desktop apps are getting closer and closer to that category.

	▲	xg15 2 days ago \| parent [-]
		Well yeah, it's obvious that companies love the "anything goes, no expectations" update model of websites and want to apply it to apps as well. I just don't think this is in the interest of users. As an exteme example, we've had the situation several times now that a useful app that was maintained by a single person was eventually sold to some adware or malware company - who quickly pushed an update to stuff the app full of ads or do worse with it. This only works because of the "ask no questions and accept the auto update" standard the industry established.

▲

xg15 2 days ago | parent | prev | next [-]

In the interest of openness and honesty to the user, that would be more reason to document those preparations in the changelog, so users know what to expect later on, if more features are activated.

▲

brvier 2 days ago | parent | prev [-]

I totally disagree, with today LLM with large context generating CHANGELOG.md based on latest modification and git release tag is quite easy.

	▲	alchemism 2 days ago \| parent [-]
		I second this. It’s now supremely easy to have a session hook which writes an atomic CHANGELOG along with ADRs for consequential decisions.