changelog: Document changes since v27.163.

[chrisbobbe]

No description provided.

[gnprice]

Thanks @chrisbobbe !

The most salient thing is that the "Highlights for users" needs to be a lot shorter. More precisely: the release notes we enter for the Play Store and App Store need to be a lot shorter than that; and this spot is where we do the work of drafting those up 🙂

See previous entries for examples. Those have sometimes bumped up against the limits imposed by the Play Store and App Store; I think 500 characters is the limit on at least one of them.

Apart from the platform-imposed hard limits, people just aren't realistically going to read more than a small handful of items here. So the main thing I do in this section is to cut it down to just the few that users are most likely to actually feel are meaningful for them.

I'll also make some specific comments inline.

[gnprice]

Comments below on the "Highlights for users" section.

I'll take a look next at the developer-facing section but not quite as closely, because it's not user-facing and doesn't have tight length constraints.

[gnprice]

This one definitely doesn't make it into this section -- most users will never see it, and for those that do, the banner is its own announcement 😉

And nobody will see this and think "ah, that's a great feature, I've been wanting something like that", or "oh that bug, so glad they fixed it." If someone's happy about this feature, it'll only be from rather abstractly reasoning through how it will help cause things to get updated.

[gnprice]

This doesn't go in this section -- most users probably never noticed that icon, and nobody will be excited it's gone. (Some will be pleased it's gone, from a UI-connoisseur perspective; but from the direct user perspective, it's the removal of an annoyance one hadn't even quite put a finger on.)

[gnprice]

And comments on the developer-facing section. Thanks again!

[gnprice]

So the way I've been compiling this "Resolved issues" list is that each item in it really is an issue, i.e. either a bug or a feature request; when I list a PR, it's because we didn't file a GitHub issue for it.

So for example, taking from the top of this list:

• accountsReducer [nfc]: Followups on handling restart events #4794 wouldn't be on that list
• accountsReducer: Use restart events to update server info when we can. #4707 would, as it implements a feature
• Run yarn upgrade, after treating some deps individually. #4789 wouldn't
• Flow-related work on the path to RN v0.64 upgrade, part 2. #4520 wouldn't
• Followups on open-links-where setting, #4679 #4766 wouldn't, even though it's a GitHub issue -- it was really a code review, reified as a GitHub issue just to help with task-tracking
• dependabot: Remove config file. #4787 wouldn't. Though there might be an item above saying we tried out Dependabot, and mentioning dependabot: Remove config file. #4787.
• build(deps-dev): bump eslint from 7.14.0 to 7.28.0 #4785, build(deps): bump react-redux from 7.2.1 to 7.2.4 #4784, build(deps): bump @sentry/react-native from 2.2.1 to 2.4.3 #4780, build(deps-dev): bump eslint-plugin-react from 7.21.5 to 7.24.0 #4786 wouldn't -- just automated upgrades
• flipper ios: Pin to some specific versions, to fix build with Xcode 12.5. #4721 would, as it fixes a build issue. Oh but it'd go closer to the end of the list, because it was merged May 6.
• deps: Remove prop-types from devDependencies. #4779, dependabot: Add config file. #4778, build(deps): bump ini from 1.3.5 to 1.3.7 #4334, build(deps): bump ua-parser-js from 0.7.21 to 0.7.28 #4727, build(deps): bump y18n from 3.2.1 to 3.2.2 #4574, build(deps): bump lodash from 4.17.20 to 4.17.21 #4737 wouldn't -- Dependabot upgrades, and the change to enable it
• Stream settings screen doesn't make sense for non-subscribed streams #4715 definitely would -- a buggy bit of UI
• (OK, that gives the idea.)

It wouldn't be unreasonable to have a list that includes all kinds of changes, even those that aren't issues. Possibly it'd be less work to compile that way -- though I think probably not, as it makes the list quite a bit longer.

Definitely quite reasonable to experiment with different ways of writing these notes.

If we do make this list broader, though, it should have a correspondingly different heading. "Resolved issues and merged PRs"?

[chrisbobbe]

Would the many muted-user PRs all get listed here? The umbrella issue, #4655, is quite near to being resolved but hasn't been yet.

[gnprice]

I think in that situation it'd be OK to say something like "most of #4655".

But also, that is perhaps a hint that it's time to close #4655 as resolved, and file new issues for specific known things that are missing 😉

[chrisbobbe]

I think in that situation it'd be OK to say something like "most of #4655".

Done in my next revision 🙂

[chrisbobbe]

Thanks for the reviews! Revision pushed. Please see a question at #4800 (comment); I've left all the muted-users PRs in the "Resolved issues" list for this revision but it'd be easy to do something else.

[gnprice]

Thanks for the revision! Looks good modulo the bit about the muted-users PRs.

[chrisbobbe]

Thanks for the review! Revision pushed.

[gnprice]

Thanks! Looks good except for this stray heading at the top, new in this revision:

+## 27.163 (2021-06-04)
+

I'll go ahead and merge after removing that.

[chrisbobbe]

Thanks! Looks good except for this stray heading at the top, new in this revision:

+## 27.163 (2021-06-04)
+

I'll go ahead and merge after removing that.

Oops, thanks; I added this temporarily so that tools/changelog czo would work, so I could easily get the issue/PR numbers linkified and look through them more easily :)