Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A strong commitment to backwards compatibility means keeping your mistakes

utcc.utoronto.ca

Post reply on HN
Print view View original

31–40 of 62 posts

Re: A strong commitment to backwards compatibility means keeping your mistakes

#31

Post by humanrebar »

okamiueru wrote: post #24
WhyNotHugo wrote: post #14

The reality is that you have to be sensible and balanced. You can't keep BROKEN functions "because people rely on them", but you can't suddenly make a minor release (e.g.: from 2.3.4 to 2.3.5) completely changing the semantic of a feature you expose. You need to: - Avoid changing APIs just for the sake of change. - Announce breaking changes. - Document how users are intended to migrate from your old API to the new on…

Most of what you touch on is covered by semantic versioning. ( https://semver.org ), and IMO should be mandatory reading by anyone in software development. It sort of looks like you are sort of aware of it, but maybe not entirely. What you called a minor version is typically called a "patch" version. So it goes. MAJOR.MINOR.PATCH Major version bump can change anything. Minor versions are generally safe to upgrade, bu…

The biggest problem I have with semver is that we don't have good enough tooling to reject minor or patch version bumps when major version bumps are actually warranted. I'm not sure it's possible to have that thorough of analysis in general.

Semver is handy for understanding what the maintainer meant to do. I guess in a lot of circumstances that's not nothing.

Re: A strong commitment to backwards compatibility means keeping your mistakes

#32

Post by account42 »

okamiueru wrote: post #24
WhyNotHugo wrote: post #14

The reality is that you have to be sensible and balanced. You can't keep BROKEN functions "because people rely on them", but you can't suddenly make a minor release (e.g.: from 2.3.4 to 2.3.5) completely changing the semantic of a feature you expose. You need to: - Avoid changing APIs just for the sake of change. - Announce breaking changes. - Document how users are intended to migrate from your old API to the new on…

Most of what you touch on is covered by semantic versioning. ( https://semver.org ), and IMO should be mandatory reading by anyone in software development. It sort of looks like you are sort of aware of it, but maybe not entirely. What you called a minor version is typically called a "patch" version. So it goes. MAJOR.MINOR.PATCH Major version bump can change anything. Minor versions are generally safe to upgrade, bu…

I think GPs main point is not covered by semver at all - namely to not break anything out of the blue but have a transition period where API consumers can upgrade at their own leisure.

Re: A strong commitment to backwards compatibility means keeping your mistakes

#33

Post by account42 »

humanrebar wrote: post #31
okamiueru wrote: post #24

Earlier quoted context omitted.

Most of what you touch on is covered by semantic versioning. ( https://semver.org ), and IMO should be mandatory reading by anyone in software development. It sort of looks like you are sort of aware of it, but maybe not entirely. What you called a minor version is typically called a "patch" version. So it goes. MAJOR.MINOR.PATCH Major version bump can change anything. Minor versions are generally safe to upgrade, bu…

The biggest problem I have with semver is that we don't have good enough tooling to reject minor or patch version bumps when major version bumps are actually warranted. I'm not sure it's possible to have that thorough of analysis in general. Semver is handy for understanding what the maintainer meant to do. I guess in a lot of circumstances that's not nothing.

> The biggest problem I have with semver is that we don't have good enough tooling to reject minor or patch version bumps when major version bumps are actually warranted. I'm not sure it's possible to have that thorough of analysis in general.

The biggest problem with automated tooling is that there is a nontrivial subjective component to this. If you look at things strictly, any bug fix that changes externally observable behavior can be a breaking change - but bumping the major version for every release defeats the purpose of SemVer.

Re: A strong commitment to backwards compatibility means keeping your mistakes

#34

Post by cecilpl2 »

okamiueru wrote: post #24
WhyNotHugo wrote: post #14

The reality is that you have to be sensible and balanced. You can't keep BROKEN functions "because people rely on them", but you can't suddenly make a minor release (e.g.: from 2.3.4 to 2.3.5) completely changing the semantic of a feature you expose. You need to: - Avoid changing APIs just for the sake of change. - Announce breaking changes. - Document how users are intended to migrate from your old API to the new on…

Most of what you touch on is covered by semantic versioning. ( https://semver.org ), and IMO should be mandatory reading by anyone in software development. It sort of looks like you are sort of aware of it, but maybe not entirely. What you called a minor version is typically called a "patch" version. So it goes. MAJOR.MINOR.PATCH Major version bump can change anything. Minor versions are generally safe to upgrade, bu…

https://medium.com/@xzyfer/why-node-sass-broke-your-code-and...

What do you think of this example, where a library made a breaking, non-backwards compatible change, causing user code to throw fatal errors.

They defended their point that this is only a minor version increment since the working user code was actually erroneously working and should have been throwing fatal errors the whole time.

Re: A strong commitment to backwards compatibility means keeping your mistakes

#35

Post by cecilpl2 »

I'm reminded of a story told by Joel Sposky about Simcity on Windows 95.

The DOS/Win3.x version of SimCity had a bug where it used memory after freeing it, which worked fine on DOS since the memory didn't get reallocated. The Windows 95 team found that it was broken, and so they added code to detect whether SimCity was running, and if so ran the memory manager in a special mode that didn't release memory immediately.

Re: A strong commitment to backwards compatibility means keeping your mistakes

#36

Post by skeeter2020 »

cecilpl2 wrote: post #35

I'm reminded of a story told by Joel Sposky about Simcity on Windows 95. The DOS/Win3.x version of SimCity had a bug where it used memory after freeing it, which worked fine on DOS since the memory didn't get reallocated. The Windows 95 team found that it was broken, and so they added code to detect whether SimCity was running , and if so ran the memory manager in a special mode that didn't release memory immediately…

people love to credit MS's success to their ruthless monopolistic practices and there is truth to that, but they've also (a) treated developers very well and (b) put tremendous effort into backwards compatibility. Neither of these are trivial but I don't think there's another player out there who has done this as well.

Re: A strong commitment to backwards compatibility means keeping your mistakes

#37

Post by WhyNotHugo »

cecilpl2 wrote: post #34
okamiueru wrote: post #24

Earlier quoted context omitted.

Most of what you touch on is covered by semantic versioning. ( https://semver.org ), and IMO should be mandatory reading by anyone in software development. It sort of looks like you are sort of aware of it, but maybe not entirely. What you called a minor version is typically called a "patch" version. So it goes. MAJOR.MINOR.PATCH Major version bump can change anything. Minor versions are generally safe to upgrade, bu…

https://medium.com/@xzyfer/why-node-sass-broke-your-code-and... What do you think of this example, where a library made a breaking, non-backwards compatible change, causing user code to throw fatal errors. They defended their point that this is only a minor version increment since the working user code was actually erroneously working and should have been throwing fatal errors the whole time.

If it broke the exposed API, it should not be a minor.

It doesn't matter if it's "by design" or not, people still rely on it and semver is how you communicate the breakage to them.

Re: A strong commitment to backwards compatibility means keeping your mistakes

#38

Post by PeterisP »

WhyNotHugo wrote: post #19
MaxBarraclough wrote: post #17

Earlier quoted context omitted.

> This gives consumers of the API plenty of time and margin to experiment with both and move on. It's not a silver bullet though, as we saw with the move to Python3. It annoyed people with large Python2 codebases, giving them the choice between: • Laboriously reworking their code to transition it to Python3 (a language with only limited advantages over Python2) • Using an unsupported language for a significant codeba…

Python 2-3 is a great COUNTER example of what I'm saying. There was no intermediate release that could run both python2 and python3 code. It introduced new features AND removed the old ones all at once.

You could transform your 2.x code so that it would run on both 3.x python and also on recent 2.x python versions, using new features with appropriate `from __future__ import` statements; so in that regard the latest 2.x versions were those intermediate releases that could also run 'new style' code. I had a bunch of internal code that would run on both 2.x and 3.x python, and many libraries also did just that.

Re: A strong commitment to backwards compatibility means keeping your mistakes

#39

Post by beckingz »

WhyNotHugo wrote: post #37
cecilpl2 wrote: post #34

Earlier quoted context omitted.

https://medium.com/@xzyfer/why-node-sass-broke-your-code-and... What do you think of this example, where a library made a breaking, non-backwards compatible change, causing user code to throw fatal errors. They defended their point that this is only a minor version increment since the working user code was actually erroneously working and should have been throwing fatal errors the whole time.

If it broke the exposed API, it should not be a minor. It doesn't matter if it's "by design" or not, people still rely on it and semver is how you communicate the breakage to them.

What if it counts as a bug fix?

Re: A strong commitment to backwards compatibility means keeping your mistakes

#40

Post by dagw »

madia_leva wrote: post #18
taffer wrote: post #12

Earlier quoted context omitted.

Suppose you create an API that allows users to enter nonsensical data or do things that are very bad for performance. Later, you realize your mistake, create a new, improved version of your API, and deprecate the old API. However, as long as you keep the old API for backward compatibility, you will have to deal with nonsensical data and poor performance.

You won't have to deal with it. Whomever is using that old API has to deal with it. Their choice. We are talking about an API, not a shared service.

We are talking about an API, not a shared service.

That distinction is becoming a lot blurrier than it used to be as more and more "APIs" now are run as shared services with no option of running them locally.

Post reply on HN