131–140 of 159 posts
Sooo adding a field to a struct is supposedly a non-code-breaking feature (yeah, right) but tweaking a constant isn't? This does not fit with my experience of the world.
Earlier quoted context omitted.
No, it isn't computable (that is, correctly determining one of "these functions behave the same" or "these functions behave differently", and not "unknown") in general, as it is equivalent to the halting problem. Consider these two versions of a function, are they API compatible? def foo(): return True def foo(): return halts("some turing machine program") They're only truly API compatible if the program halts, but t…
It's been a while, since I studied this, but linear bounded automata are arguably a better model for the real computers we can actually build and the halting problem is computable for LBAs.
If your language lets you build a neverending loop/datastructure/etgc, then you cannot prove halting for all the programs that can be made by the language.
Since such languages exist, then by extension, it applies to computers.
Kind of contradicts "Often, it seems that version numbers are incremented by "gut feel" instead of any consistent semantic: "This feels like a minor version update."
> The value of MaxBufferSize was adjusted downward to 2048 because we discovered a buffer overflow in a lower level library for any larger buffer size. See issue #4144
Technically it's a major version bump, as I understand it. But security is important, so what should we do here in addition to writing it down as first sentence on release notes? Perhaps having an excuse to potentially break downstream code in the name of security should be OK and well communicated (i.e in readme)?
Django is my gold standard for this. They have great deprecation policies where they deprecate something in the same release that they add alternatives (allowing for you to fix things up before upgrading Django), they document these changes liberally and offer alternatives, make good use of the warnings system (meaning you can run tests in "deprecated functions not allowed" mode to catch stuff), and generally are car…
It's also amazing how long they stayed at 0.96 despite being very stable. Then 1.x for a long time too.
It has a cost though: django has a hard time going async since it breaks everything.
All in all, the python community has a good culture for this. Even the 2 to 3 migration was given more than a decade to proceed.
Yet, i feel like we still get a lot of complains, while in js or ruby land you can break things regularly and fans scream it's fine.
Sooo adding a field to a struct is supposedly a non-code-breaking feature (yeah, right) but tweaking a constant isn't? This does not fit with my experience of the world.
Could you describe some situations where adding a field broke stuff? I can only imagine that happening if your code cares about the exact binary representation/layout of a struct - so serialization, FFI or just bit-twiddling.
On the other hand, a large number of constants are supposed to be tweakable, to the extent that many are designed to be set at compile time.
Anyway. OP article had good points overall, I'm just not sold on some of the specifics.
Earlier quoted context omitted.
Irrelevant?? That is the most relevant question that a developer could ask in this situation. Often, there are ways to work around bugs in an API. And, just as often, those workarounds will break as soon as the bug is fixed. The API developer is in a particularly poor place to judge whether a bug fix is breaking or not. Sometimes, they can talk to users to see if a change will break their code, but other times they c…
Irrelevant?? That is the most relevant question that a developer could ask in this situation. No, it isn't. The most relevant question is "can somebody be using the current API". It doesn't matter if your current API matches the documentation, what matters is whether your current API is out there for others to build on. Don't try to use a crystal ball or other form of divination to predict what your downstream users…
Semver both acknowledges and is predicated upon the fact that every bug fix has a range of possible impacts. At one end, some bug fixes have almost no chance of breaking an application. At the other end, some bug fixes will almost certainly break applications.
This is not divination. It is understanding your application and its users.
Finally, in regards to your last paragraph, I genuinely hope that you don't speak to developers like that. Mistakes will always happen. Have a little bit of respect and treat people with kindness.
Earlier quoted context omitted.
Well, if you wrote stable code in the first place, there wouldn't indeed be any need for updates!
Jokes aside, a lot of developers would call a project "dead" when is working as intended and not receiving new commits.
Earlier quoted context omitted.
Irrelevant?? That is the most relevant question that a developer could ask in this situation. No, it isn't. The most relevant question is "can somebody be using the current API". It doesn't matter if your current API matches the documentation, what matters is whether your current API is out there for others to build on. Don't try to use a crystal ball or other form of divination to predict what your downstream users…
Using that logic, every single bug fix that even remotely changes how the API operates would be considered a major version. What would be the point of semver? Semver both acknowledges and is predicated upon the fact that every bug fix has a range of possible impacts. At one end, some bug fixes have almost no chance of breaking an application. At the other end, some bug fixes will almost certainly break applications.…
Yes. That's exactly how SemVer works. It signals to people that there was a breaking API change - it doesn't matter if you're on version 10495.0.3 - if you've somehow broken your API 10,494 times you're following SemVer. Although if you're that bad at maintaining a stable API you probably don't have any users you know... using it.
SemVer is predicated upon the fact that other people are using your API. It signals to them whether or not it should be safe to update without breaking their code that relies on your API. If you break your API - you broke their code. That makes you an asshole in their eyes. The entire point of SemVer is to signal that you broke your API so that people relying on it can examine their code for breakage, decide whether or not to update, or start working on modifying their code to match the new API.
If your API is very unstable then people aren't going to rely on it. If it's both unstable and you don't signal breaking changes I'd be amazed if anyone put up with working with it.
If I'm using version 3.0.2 I should be fine using any 3.y.z version. If you release a 4.0.0 then I know I need to investigate and determine whether or not it is safe for me to update to that version. If your API is still unstable and changing on a daily basis - you shouldn't be at 1.0.0 yet. 1.0.0 is meant to signal the "stable API stage" of development.
Earlier quoted context omitted.
Irrelevant. If fixing a bug is a breaking change then it is a breaking change. This is the importance of pre-releases/"nightly" branches so that you don't have a mistake of addNumbers(5,5) returning 25 instead of 10 and not being caught and then needing to increment a major number to fix a typo of × to +. A bug fix is a change . A breaking change is a change that breaks the API . Doesn't matter if the previous status…
A bug fix is not a breaking change. You are speaking in tautologies. "A bug fix is a change that is a change to the API". No, bug fix does not change the interface. A bug fix does not change the API. It does not require a semantic version change unless it also changes the expected behavior of the method, in which case it is a change in the documentation, which is part of the application programming interface.
Doesn't matter if it breaks it in a way that you don't expect users to have been using it - you broke it. Doesn't matter if you were just fixing a typo that changed behavior - you broke it. Doesn't matter if you were fixing a logical error - you broke it. Doesn't matter if you fixed the PRNG causing some results to no longer be possible - you broke it. Doesn't matter if you deleted a deprecated endpoint - you broke it. '
SemVer isn't asking why you broke it - it's asking did you break it.