[joepie91_]

> 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 were, then they should already have this information!

Honestly, if you don't have a release manager with a 30,000 foot view of the operation, you probably have bigger organizational problems than "it's hard to know what to fill in on the app store's release notes".

This is how retrospectives on supply chain attacks start, basically.

[JimDabell]

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

The change log that the App Store presents to the user is static and identical for everybody. The changes that a user actually experiences are not. So you might have 0% of your users experiencing a certain feature when the release goes out, 10% a day later, 50% a day after that, and 100% at the end of the week. Or, if the metrics show a bad response, it might end up at maximum 10% seeing it, and then it dropping back down to 0% the next day.

Apple gives you a static text field to enter the change log information, with limited length. If you have ten different features to release, your users will all receive them at different times, and not all of them are guaranteed to make it out to everybody, how is a static text field supposed to deliver that information?

[Master_Odin]

"Begin rollout of feature <foo>" "We are rolling out <foo> in <timeframe> to ensure <x> about <y>, and rollback if <z>. You will notice you have <foo> when <bar>."

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.

[JimDabell]

> "Begin rollout of feature <foo>" "We are rolling out <foo> in <timeframe> to ensure <x> about <y>, and rollback if <z>. You will notice you have <foo> when <bar>."

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.

[SpicyLemonZest]

Many applications are big enough that no single person can hold the full details of what’s being released in their head. If a release contains a hundred changes from a dozen teams, there’s no way a VP or CTO sitting on top can understand them all in any depth, so “performance improvements + bug fixes” may well be the full contents of the 30,000 foot view.

That doesn’t mean it’s impossible to produce more detailed notes for a big application, but it’s a pretty involved process basically requiring a “release note manager”, not something that happens by default.

[toast0]

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

[damnyou]

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.