Sometimes the best of the last generation is better than the new of the next. While I don't know how strongly this author makes that case, it's true in a general sense.
Sometimes the best of the last generation is better than the new of the next. While I don't know how strongly this author makes that case, it's true in a general sense.
If it's not worth spending one of your innovation tokens[0] on this new fangled technology, then use the old version that doesn't require the bleeding.
Also related is my policy of "never rely on anything until it reaches at least version 3". (Figuratively speaking, as version numbers don't really mean what they used to)
How far back do you lag to feel safe?
There's a thought that Nassim Nicholas Taleb mentions in one of his books that I've frequently used as a mental model ever since coming across it: For a book that has continuously been read for the last 100 years, you can expect it will continue to be read for the next 100 years. For a book that has only come out last year and been continuously read since then, you should have an expectation that one year from now, people will stop reading it.
10 years is a number I've arrived at by experimentation, thinking about version histories of various bits of software I build upon. For example, for Python this takes me back to version 3.4, before type decorators and many other things hit the scene that I disapprove of anyway. So now, I test all my code with both version 3.4 and the newest version (3.11). I won't use language features from 3.11 that weren't already there in 3.4, and I won't use code in 3.4 that breaks or throws deprecation warnings in 3.11. I also apply this test to dependencies, seeing what happens if I try to get the newest version of some Python library running on version 3.4 of the interpreter.
This means, my code is engineered in such a way that it could have been in continuous operation for the last 10 years, while running continuous updates on what's underneath it. And this gives me a reasonable expectation that my code will require only minimal code changes over the next 10 years to keep up with whatever might arise.
With the python interpreter itself, it's remarkably easy to do that, and I feel it doesn't limit me in my own coding in any meaningful way. With other bits of software, including many python libraries that one might depend on, it would be absolutely unworkable. In such a case, I take that as a clear signal not to use the software/dependency at all.
This is a lot of work, but also a good forcing function that prevents me from becoming a dependency hog myself. It's also useful research, because I get to develop an understanding of what time does to a piece of software, i.e. what causes breakage through time versus what causes stability through time, because I see the breakage in other bits of software through the time axis that I simulate into the past. And this way, I can avoid those mistakes when designing my own software.