back

by jasonpeacock·5y ago·view on hn ↗
What I like about regular, shorter (12mo vs 18mo) is it helps users exercise their "upgrade muscles".

For those that care, they can establish procedures and then practice them (and improve them) to update their dependencies. This helps immensely down the road when security patches are released or other dependencies have significant updates. It turns such updates into boring non-events.

Otherwise users only update their dependencies due to security threats or dead dependencies, and it always results in a stress-filled circus usually followed by outages & bugs.

5 comments
I would counterargue that it adds stress for no good reason, and it leads to exactly the opposite result.

If I want to collaborate with someone we now need to agree on multiple versions of multiple libraries - if my code needs at least version 3.6 because I use f-strings but their code needs 3.5 because a library will otherwise break, we now have a stress point that we don't need.

Even worse, I might have to collaborate with someone who is not a programmer (very common in data science) and now I need to spend an hour guiding them through the update process plus time in the future to fix whatever the upgrade broke in the background. For a language that made "easy to use" a selling point, that is less than ideal. (Side note: it also makes Python the only language for which I regularly need to check the date in Stack Overflow answers, as those get outdated faster than, say, Bash scripts).

How does that get solved in practice? In my experience, by pinning everything to 3.5 or 3.6 and never updating.

> If I want to collaborate with someone we now need to agree on multiple versions of multiple libraries - if my code needs at least version 3.6 because I use f-strings but your code needs 3.5 because a library will otherwise break, we now have a stress point that we don't need.

The longer the interval between releases the more likely that kind of library incompatibility is, and the more likely an upgrade becomes too much trouble to be worthwhile. If you have to upgrade one library to be able to upgrade your Python version, you can probably manage to test that. If you have to upgrade four libraries you're more likely to give up and pin to the version you're currently on.

I think the kind of breaking changes people want to actually use are less frequent than incompatible changes in general. E.g. this zoneinfo library is something where the reaction is "great, I can drop a dependency in 3-4 years" while fstrings are a lot more compelling to some people as it fixes a papercut they have with long format calls. I don't see many libraries raising their minimum python version for zoneinfo as a result, while libraries did for fstrings.
Withstanding stress is a sufficient good reason. When you need to deploy a security fix with a deadline of a week ago, it has to go smoothly; and it's going to go smoothly because everyone involved knows how to update everything reliably and efficiently.

> now I need to spend an hour guiding them through the update process

The update process should consist of deleting site-packages and Python binaries, installing Python, and running a simple script consisting mainly of "pip install x y z" steps. Or nowadays replacing a whole Docker coffin with an updated one. Can you elaborate on the required "guiding"?

Python's release policy is pretty sane as they try to overlap maintenance periods. Python 3.8 will still be supported for another 3+ years after 3.9 is released.
Three years is like tomorrow for breaking changes. I have come to apriciate the slow moving tools more and more the older I get.
There aren't any breaking changes in 3.9.
I quite value learning languages deeply. That isn't really possible when you're continually bridging multiple subtly incompatible python versions. Great for throwaway code, not for building anything of value.
This is true, but shorter intervals are also exhausting. It gets less tiresome with practice, but I really wish there was a stable environment to work in sigh.
You can always pin to an older version for both your runtime and your libs. That seems, naively, like it would produce exactly what you're looking for. Perhaps I'm mistaken.

Though this will tend to come at the cost of making upgrades and patches into significantly more work, as they will be larger and you less used to doing so. As the user said, "a stress-filled circus usually followed by outages & bugs".

What kind of stable environment to work in do you imagine?

The problem is when you depend on a SAS like Google Cloud Storage or some such. If you stay pinned, eventually the service can break. I don't have a great solution, it's just such a grind to keep things updated.
I agree. It's such a pain when one cannot simply sit athwart the world and command "Stop!". I find the world can be a very inconvenient places at times.

From where I'm sitting, the best option on offer for coping with this inconsiderate world is to keep in practice applying your updates on a regular cadence. It may be a grind, but it's perhaps one that gets easier as you do it more often. It certainly makes for smaller, more regular updates that in my experience are often more manageable.

So skip a minor version here or there. Problem solved.
Indeed, imho it's also better to have more smaller update cycles with their associated issues spread over time then having all those issues at the same time while external pressure is also pushing. to get that security fix or bussines critical feature out.
This might work acceptably if you do most or all of your programming in Python anyway. However, if you try doing it as someone who works on a lot of different projects within that 12-18 months, using many different languages, then the kind of dependency hell that exists in ecosystems like Python and JavaScript gets old very fast. In that environment, having every language you use invent its own toolchain and conventions for package and dependency management is anything but helpful.

There is a lot to be said for having language tools that compile your code, compile or directly link in any external libraries from wherever you chose to put their files, and then simply give you back a single native executable file.