I upgraded a Linux server one time and data that was serialized in yaml stopped being parsed properly.

It turns out the libyaml people decided to change how hashes were handled, which made any previous hashes come back as blank.

A whole database of valid data in dev was coming back invalid in prod. It was maddening.

It took a day to figure out the problem and how to update the data to the new format in rails.

I now serialize in json.

So what changed?

See this madness @JS96

Where is the backwards compatibility ?

Wondering what is best, having MS still making sure old systems doesn't break or Linux changing stuff and breaking old data just because someone had a wonderful idea on changing a library...

@Grumm Keeping the dependency tree flat and version pinning combined with semantic versioning are key to avoid frustration. Breaking changes normally have a good reason to be made, but the casual minor update shouldn't break stuff.

Additionally, deprecating old stuff first while keeping support for it for some years allows hobbyists to keep up with innovation too (but Python 2 definitely has been supported for waaaaaay too long).

In the end you want both: Backward compatibility and innovation. Microsoft shines there for everything not involving drivers (oh boy do they love breaking drivers) - where instead Linux shines. So OS-wise you have to decide between software and hardware backwards compatibility - or use Wine on Linux to get the best of both worlds...

@Grumm imagine combining the two things and updating an API to handle both cases.
Wonderful, isn't it? 😁

As stated in my rant, I said that a real solution should prevent issues with legacy apps, but also make the life easier for modern computer usage, since the technology is evolving.

I never said that Apple, Linux, PHP, etc. approach is better. Of course it's easier to say "Upgrade along us or die" than making stuff work for ages.

@Oktokolo If I recall correctly, hashes used to start with -- but the new version didn't, and there was no effort to maintain backward compatibility. So loading previously valid yaml data with the new library returned a blank or nil instead of erroring out.

That may not be 100% correct since it's been so long and I haven't purposely used yaml for anything since.

The real problem is upgrading without any form of validation / migration / regression check.

Don't add workarounds, migrate.

Don't add dead code, migrate.

Don't let libraries rot away in old versions, migrate.

Be proactive, check in regular intervals release notes of libraries and make sure that an upgrade is possible.

Any packaging tool has for years the possibilities to do this - adding a bit of scripting, you can get an automatic report with highlights in few minutes.

It's not breaking backwards compatibility which is bad....

... But rather mismanagement and ignoring maintenance and waiting till everything's unmaintainable.

Most small version bumps take 5 mins.

Wait a year, bump several major versions and yes - you get clusterfuck, that takes days to unfuck.

@cuddlyogre Yaml always had hashes/maps start by just writing down a key/value pair like "key: value". A single dash is used to start list elements.

@IntrusionCM I am a lone dev working with a large codebase that came to me with no tests.

With the amount of work I have, I don't have the luxury of free time to build a test suite from scratch. I especially can't justify spending weeks on something that is, by and large, nonessential to day to day operations when paying work is waiting to get done.

We have attempted to hire people to lighten the load, but they simply don't exist in our area.

Even so. I tried to write tests for it way back when, but getting the tests to work with the database in a sane and reliable manner was nearly impossible. So even if I had a test suite, the kind of test that would have caught this particular bug would have been absent.

@cuddlyogre i know such codebases.

But I said *reading changelogs*...

Tests *might* catch regressions, but the even better way is to not upgrade at all when the list of changes isn't clear.

Might be an unpopular and unpleasant way, but thx to package management and scripting, it's easy to get it down to a manageable level of information.

Compared to writing tests, aggregating a feed of release notes is pretty easy.

@IntrusionCM Not when you inherit multiple servers at different OS versions and there is a critical exploit that can only be resolved by upgrading.

I was also still pretty new at the time.

I got the short end of the stick on this one.

@JS96 :) My comment was not to say that this approach is bad or not.

It is just not that simple. There will always be problems.

For me, PHP has done a good job in making stuff deprecate. But they made nice lists telling what was not working anymore.

Always test the code first. Sometimes if you are the only dev it is hard.

I used npm to make a Nuxt website. After an update, some random package wasn't working anymore. It was hell to find what was the problem and how to fix it.