The way I do it, patches are backward-compatible bug fixes. Minor versions are additional features that don’t change existing functionality. Major versions include breaking changes. I totally get that it seems crazy to bump to another major version just over a string format change. But overall the philosophy works well IMO.
IMO it doesn’t really matter what you said the method was for. If you change the format of a string that is returned by a method that returns a string, there’s a risk of breaking user code, even if it’s just in the context of their dev environment.
Philosophically, whether or not the behavior of your API has changed is completely disconnected from whether or not others are using it “right”. If I can depend on a function to return a certain type of value when given certain arguments, and if it doesn’t produce other side effects, then it doesn’t matter what the docs say or what the function is named, I can use it in any context where I need that type of return value and have this type of arguments available. This type of function is just mapping data to other data. If you modify the function in such a way that the return value changes after being given the same arguments, that’s a breaking change in my book.
It’s specifically the “I’m here to recognize it and acknowledge it and talk about it” part followed up by no recognizing, acknowledging, or talking about anything substantial.
They’re also a VP of Community. As someone with such a specialized purpose specifically in this area, we should have expected a better performance.
Yeah it’s interesting because JS is interpreted, not compiled. The proposal allows for type annotations in the syntax but no actual interpreter consequences. On the one hand that makes sense because otherwise you’re in the territory of runtime type-checking which would be a huge performance hit and would sort of defeat the purpose of static types anyway. But that means you still have to rely on your IDE or a linter for this to be useful.