8 ms·

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 th

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.

tehjoker 6y ago
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.
- Kalium 6y ago
  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?
  - tehjoker 6y ago
    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.
    - Kalium 6y ago
      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.
- birdyrooster 6y ago
  So skip a minor version here or there. Problem solved.
klyrs 6y ago
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.
probably_wrong 6y ago
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.
- lmm 6y ago
  > 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.
  - Macha 6y ago
    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.
- 6y ago
aequitas 6y ago
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.
Silhouette 6y ago
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.

tehjoker 6y ago

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.

Kalium 6y ago
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?
- tehjoker 6y ago
  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.
  - Kalium 6y ago
    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.
birdyrooster 6y ago
So skip a minor version here or there. Problem solved.

klyrs 6y ago

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.

probably_wrong 6y ago

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.

lmm 6y ago
> 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.
- Macha 6y ago
  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.
6y ago

aequitas 6y ago

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.

Silhouette 6y ago

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.