Thank you for choosing [app] - the best [thing] for [thing that it does]! We are committed to continuously improving the experience of bringing you the best of [thing that app does]. We update the app regularly so we can make it better for you. Get the latest version for all available [app] features. Love [app]? Rate us 5 stars!
Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
111–120 of 127 posts
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#112The 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.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#113Earlier quoted context omitted.
I'm talking about feature flag based rollouts, which don't involve going through Apple or Google.
Hope you didn't mess up your flag system. Or your feature flagged feature doesn't corrupt your locally stored state.
Yeah it happens sometimes. It sucks. It's where incident reviews come in, and feature flags are still better on balance for many apps.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#114Thank you for choosing [app] - the best [thing] for [thing that it does]! We are committed to continuously improving the experience of bringing you the best of [thing that app does]. We update the app regularly so we can make it better for you. Get the latest version for all available [app] features. Love [app]? Rate us 5 stars!
Meanwhile nothing at all changes with updates but there are hundreds of server-side settings that change all the time because metrics gotta grow. Eternally. Into infinity. And don't you dare get used to the UI.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#115Google is a serial offender
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#116That's just a consequence of the dreaded "move fast and break things" culture. Ideally, you should only be updating your app to add new features or to address issues that have arisen with an OS update or new hardware for example. And you should only be releasing new features when they're ready, not when current time matches a certain value. But for some reason you can't be doing any of that if there's money involved.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#117The 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 key is describing the user-facing effects and impact. This means knowing your users (are they developers, IT or highly technical? Do they automatically or manually update quickly, or do they take time to evaluate before rolling out updates?). It's a way to convey continuing value to users and convince them it's worthwhile to keep paying, and get motivated to get the update. I'd try to change what you wrot…
I think focusing on "user facing impact" is a good idea and something I'll be using in the future. One challenge is that developers don't always know the user facing impact of their improvements.
For example if I notice a logic error in a system and fix it, I may not know what if any software configuration could trigger the error. If it were obvious, QA would've found it. And given the choice between further investigation or leaving the bug unfixed, my employer would prefer the latter.
Or one time I was working on a new feature that required speeding up the system's implementation of malloc(). That improves the performance of the entire system to varying degrees. Pinpointing exactly where the user's experience improves would require extensive benchmarking outside the scope of the work.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#118Earlier quoted context omitted.
> 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 wer…
> 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.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#119Earlier quoted context omitted.
There’s also a mitigating liability aspect to this. If you start providing minutiae detail, you may start revealing pretty big faults that have escaped to prod. People question the safety of your product and now you’re open to lawsuit or at least micromanaged by some unforgiving end-customers. To cope, you start to not fix certain problems so you won’t have to report the bugs or you start lying what the bugs were. I’…
Back in the 80s when I was starting out in the compiler business, I thought it would be a good service to include with it a list of the known bugs. It didn't take long before a magazine reviewer did a compiler roundup and simply printed the bug list as his "review". It was a disaster for my business. It took me 20 years to get over being brutalized by that and make the bug list publicly available again. https://issue…
I had a competitor do something like this to me in the 10s.
We had a structured weekly/monthly small/big release cadence compared to their bi-annual update. When we started thoroughly documenting our bug-fixes publicly, they used that against us in negotiations on a large deal. Basically alluding that our software was buggy, seeing that we had something to fix every week. Luckily we thwarted that logical fallacy by asking how many bug fixes they did last year and had no real answer.
People suck. Glad to hear you’ve overcome the fear on this, it’s worth it and I also still maintain a public list of bug fixes.
Re: Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)
#120With 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.
You are supposed to list all the feature flags and explain how to enable them in your review notes.