4 ms·

That is just what Continuous Delivery is though. Quicker release cycles keeps breakage short. It's a lot easier to manage "this edge case broke because of somet

That is just what Continuous Delivery is though. Quicker release cycles keeps breakage short. It's a lot easier to manage "this edge case broke because of something we changed in the past day/week" compared to "something we changed in the past 3 months broke this edge case" The lack of release notes is probably just not the effort, or even confusing for users and can deter them, or make them never read the release notes when they happen. I don't think most users know what semantic versioning is. Like, if the only thing you did last week was refactor some module, add more unreachable code for a flagged feature, and update third party libraries, do the users need that info every week? But not releasing all those small changes daily/weekly makes the releases more and more dangerous as they stack up.

layer8 3y ago
A less charitable moniker for this approach is “eternal beta”.
Espressosaurus 3y ago
There's a reason why we don't do Continuous Delivery in a high reliability embedded context: the costs of bugs can be very high if it turns out to brick the device or physically damage it. As the other poster put it, it's continuous beta, and I personally am not a fan. I like my releases thoroughly tested. You updated some third party libraries, and maybe there's some subtle thing that changed in them to cause a break. Maybe that refactor wasn't zero impact the way it was intended to be. As a user, sure I want to know about third party libs being updated. All of that is useful information for us to decide to take the update or not. Back in the good old days it was all information everybody gave as a matter of course. These days, especially on phones, it's opaque and you're forced to take it whether you want to or not. edit: and the interface changing out from under us unexpectedly is incredibly off-putting. I hate that these days I never know when an application I use every day is going to decide to remove its menus or something similarly asinine inflicted on me because that's the latest trend in UX design.
alextingle 3y ago
So you fired your testing team, and replaced them with your users. Do the users get paid for that work?

layer8 3y ago

A less charitable moniker for this approach is “eternal beta”.

Espressosaurus 3y ago

There's a reason why we don't do Continuous Delivery in a high reliability embedded context: the costs of bugs can be very high if it turns out to brick the device or physically damage it. As the other poster put it, it's continuous beta, and I personally am not a fan. I like my releases thoroughly tested. You updated some third party libraries, and maybe there's some subtle thing that changed in them to cause a break. Maybe that refactor wasn't zero impact the way it was intended to be. As a user, sure I want to know about third party libs being updated. All of that is useful information for us to decide to take the update or not. Back in the good old days it was all information everybody gave as a matter of course. These days, especially on phones, it's opaque and you're forced to take it whether you want to or not. edit: and the interface changing out from under us unexpectedly is incredibly off-putting. I hate that these days I never know when an application I use every day is going to decide to remove its menus or something similarly asinine inflicted on me because that's the latest trend in UX design.

alextingle 3y ago

So you fired your testing team, and replaced them with your users. Do the users get paid for that work?