Breaking changes

There’s a specific concern about breaking changes in the upcoming 1.9.0 release. I wrote some notes on that in Add changelog for 1.9.0 by straight-shoota · Pull Request #13633 · crystal-lang/crystal · GitHub

I think the numeric bugfixes are clear.

Fix handling of quoted boolean values in `YAML::Any` by willhbr · Pull Request #13546 · crystal-lang/crystal · GitHub is a bit grey area. I probably wouldn’t consider this as breaking change. It fixes a bug and the bugfix means the previous buggy behaviour is now fixed/broken :shrug:

Remove most `LLVM::DIBuilder` functions from `llvm_ext.cc` by HertzDevil · Pull Request #13448 · crystal-lang/crystal · GitHub is also a bit difficult. It’s a hard breaking change but in an API that’s kind of semi-public and mostly intended for the compiler.
I suppose it’s fine as it is, but I wanted to point this out in case there are objections to putting this in a minor release.

7 Likes

I’m now pretty convinced that #13546 should not be considered a breaking change. Every single bug fix is a breaking change for code that relied on the erroneous behaviour. Maybe sometimes this can warrant special attention as a breaking change.
But in this case it was very clearly broken and never intended nor according to the specification.

I’m dropping the breaking change label from this.

3 Likes

I agree. And even the NaN comparisons to me are not breaking change. Bug fixes always change existing behavior, but if we are not dropping functionality or change the designed functionality I don’t think is a breaking change.

I don’t mind using breaking change to highlight strongly some bugfix and bring more awareness

2 Likes

The issue with the big number comparisons is that it may affect code that worked perfectly before (comparing with a float which could never be NaN) and might not compile any more.
So I think this warrants a special highlight.

With these kinds of fixes where something was “broken” before and fixing it will cause issues for anyone who (perhaps inadvertently) relied on the broken behaviour, why not have a different label?

Like, unbreaking_bad ? :wink: