4 ms·

The reliable bug behavior is an underappreciated point and can be hard to understand. I work on software that gets deployed on-prem by customers and had very po

The reliable bug behavior is an underappreciated point and can be hard to understand. I work on software that gets deployed on-prem by customers and had very powerful capabilities for deploying your own code to it etc. There have been a few discussions about some bug fixes and in particular security fixes being appropriate in a patch release when following SemVer. Something might be unintentional or insecure, but customers might be building on the broken behavior and now deploying a patch breaks their apps. The line can become quite blurry.

pc86 3y ago
This sounds like more a deployment/release process problem than anything else. If the customers are essentially deploying untested code straight to production, they're doing something wrong. It might not be their fault, maybe they don't know they should have a staging environment first, or maybe your pricing model makes it prohibitively expensive. It's not as simple as "your customers are doing it wrong," but if you upgrading a package breaks their production environment, someone somewhere is - or more likely, many people are - definitely doing something wrong.
- danbruc 3y ago
  It is not necessarily about breaking the production system, just breaking the system because it depends on some bug or contains workarounds that break if the bug is gone. Even if it breaks before production it is still broken and might - depending on how old or central the bug was and how much code was build on top or around it - require substantial effort to fix.
  - pc86 3y ago
    100% agree it just sounded like in this instance the first time they'd hear about it breaking a customer's workflow[0] would be in that customer's production environment. I've been on both ends of solutions where customers are either technically or financially incapable of having robust test environments for even critical software, especially if they're relying on someone else to write it. [0] https://xkcd.com/1172/ https://xkcd.com/1172/
birdyrooster 3y ago
Yes this happens all the time, I’ve seen it everywhere I’ve every been an engineer. Bug fix roll back due to causing an outage because it broke the defacto API being depended on.
fivre 3y ago
I have had this concern raised, and I'm unclear how, if you adhere to that model of compatibility, that you don't effectively dispense with semver altogether and make every release a major version bump, as every change is breaking if you relied on broken or insecure behavior in earlier versions. IMO it makes more sense to communicate the expected impact of the changes, so that downstream can read a patch bump as unlikely to cause issues.
- ajmurmann 3y ago
  Yeah, it gets fuzzy and loses clear meaning. Unfortunately, major releases are expensive in that support contacts are typically guarantee support durations for major or minor releases. Having dozens of versions that all require separate patches quickly can absorb much of your orgs productivity.

pc86 3y ago

This sounds like more a deployment/release process problem than anything else. If the customers are essentially deploying untested code straight to production, they're doing something wrong. It might not be their fault, maybe they don't know they should have a staging environment first, or maybe your pricing model makes it prohibitively expensive. It's not as simple as "your customers are doing it wrong," but if you upgrading a package breaks their production environment, someone somewhere is - or more likely, many people are - definitely doing something wrong.

danbruc 3y ago
It is not necessarily about breaking the production system, just breaking the system because it depends on some bug or contains workarounds that break if the bug is gone. Even if it breaks before production it is still broken and might - depending on how old or central the bug was and how much code was build on top or around it - require substantial effort to fix.
- pc86 3y ago
  100% agree it just sounded like in this instance the first time they'd hear about it breaking a customer's workflow[0] would be in that customer's production environment. I've been on both ends of solutions where customers are either technically or financially incapable of having robust test environments for even critical software, especially if they're relying on someone else to write it. [0] https://xkcd.com/1172/ https://xkcd.com/1172/

birdyrooster 3y ago

Yes this happens all the time, I’ve seen it everywhere I’ve every been an engineer. Bug fix roll back due to causing an outage because it broke the defacto API being depended on.

fivre 3y ago

I have had this concern raised, and I'm unclear how, if you adhere to that model of compatibility, that you don't effectively dispense with semver altogether and make every release a major version bump, as every change is breaking if you relied on broken or insecure behavior in earlier versions. IMO it makes more sense to communicate the expected impact of the changes, so that downstream can read a patch bump as unlikely to cause issues.

ajmurmann 3y ago
Yeah, it gets fuzzy and loses clear meaning. Unfortunately, major releases are expensive in that support contacts are typically guarantee support durations for major or minor releases. Having dozens of versions that all require separate patches quickly can absorb much of your orgs productivity.