6 ms·

Please do the opposite. Let all deprecation warnings last at least a decade, just include in the warning that it is not maintained. But more to the point, go

Please do the opposite. Let all deprecation warnings last at least a decade, just include in the warning that it is not maintained. But more to the point, go out of your way to avoid breaking backwards compatibility. If it's possible to achieve the same functionality a different way, just modify the deprecated function to use the new function in the background. My biggest problem with the whole static typing trend is that it makes developers feel empowered to break backwards compatibility when it would be trivial to keep things working. edit: Not that it is always trivial to avoid breaking backwards compatibility, but there are so many times that it would be.

jkubicek 10mo ago
> just include in the warning that it is not maintained. I'm convinced this isn't possible in practice. It doesn't matter how often you declare that something isn't maintained, the second it causes an issue with a [bigger|more important|business critical] team it suddenly needs become maintained again.
- tux3 10mo ago
  And here's where your business can contact me to talk about a support contract. If it's important, they'll pay. Often you find out it wasn't that important, and they're happy to figure it out.
  - nisegami 10mo ago
    It sounds like you're imagining open source whereas the comment you're replying to is imagining more intra-company dependencies.
    - mbreese 10mo ago
      I think deprecation in intra-company code is a completely different beast. You either have a business case for the code or not. And if something is deprecated and a downstream project needs it, it should probably have the budget to support it (or code around the deprecation). In many ways, the decision is easier because it should be based on a business use case or budget reason.
      - zamadatix 10mo ago
        The business case is the easy part, the quagmire is in getting the different teams to agree who should support the business case, why it's more important than the business cases they wanted to spend cycles on instead, and how much of the pie supporting it takes on the budget side. Less so when the place is small enough everyone knows everyone's name, more so when it's large enough they really don't care what your business case is much even though it'd be 10x easier to support from their side instead of another.
        spockz 10mo ago
        Oh. But that is a solved problem. The users of the library just copy the code from before the deprecation and then stick it in their codebase not to be maintained anymore. Problem solved. /s
- taeric 10mo ago
  I don't know that I see why/how this is a problem? You would do the same with any other thing in your life? More, in many things, we have actively decided not to do something anymore, and also highly suggest people not mess with older things that did use it. See asbestos. Removing it from a building is not cheap and can be very dangerous.
- dietr1ch 10mo ago
  It also keeps slowing down development as getting a green global compile will make you still update "deprecated" functions that face breaking API changes.
- locknitpicker 10mo ago
  > I'm convinced this isn't possible in practice. I don't agree. Some programming languages started supporting a deprecated/obsolete tagging mechanism that is designed to trigger warnings in downstream dependencies featuring a custom message. These are one-liners that change nothing in the code. Anyone who cares about deprecating something has the low-level mechanisms to do so.
  - jkubicek 10mo ago
    For sure, but for this to work you need someone downstream to notice those messages and prioritize the work to migrate off the deprecated code paths. Some teams will respond, but many won't. No matter how loudly you declare that the code is deprecated, you'll still have people using it up to the point it stops working. It's far better to plan the removal of the code (and the inevitable breaking of downstream users systems) on your own schedule than to let entropy surprise you at some random point in the future.
    - locknitpicker 10mo ago
      > For sure, but for this to work you need someone downstream to notice those messages and prioritize the work to migrate off the deprecated code paths. Deprecation messages show up as compiler warnings. As a package maintainer, your job does not include taking over project management work in projects that depend on your package.
ryandrake 10mo ago
One thing I've always hated was this idea of "bitrot." That software just spontaneously stops working after time and loses backwards compatibility. Like it's some force of nature. It's not a force of nature. Bitrot is: many software developers deliberately choosing to break backward compatibility in very small ways over and over. Software written in 1995 should still work today. It's digital. It doesn't rot or fall apart. It doesn't degrade. The reason it doesn't work today is decisions that platforms and library maintainers deliberately made. Like OP. Deprecate like you mean it. That's a choice! If we want to solve bitrot, we need to stop making that choice.
- jcalvinowens 10mo ago
  Progress is often only possible by breaking things. It's not a choice, it's the only way forward. We have to optimize for the future being better, even if it makes the present a little worse occasionally. This is a huge reason why open source projects are often so much more successful than corporate clones: they actually iterate and innovate, something corporate america has forgotten how to do.
  - mxey 10mo ago
    Actually this is the reason why Win32 is the stable ABI for Linux. https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/
    - jcalvinowens 10mo ago
      While I certainly empathize with the author of that article and respect the work they put into debugging it, this is a better explanation of that whole thing: https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash
  - ryandrake 10mo ago
    It's absolutely a choice. All software can progress while preserving backward compatibility for existing users. It's not always easy, but it's never impossible.
mxey 10mo ago
> Not that it is always trivial to avoid breaking backwards compatibility, but there are so many times that it would be. In this case it was 2 functions with 1 line of code each. https://github.com/urllib3/urllib3/pull/3732/files https://github.com/urllib3/urllib3/pull/3732/files
- Spivak 10mo ago
  Wow. Why even remove it? It's just the thinnest wrapper around the dict and since the dict is now part of the public API these methods will work forever unmodified.
shadowgovt 10mo ago
As with all things, this can be pushed too far. Microsoft was suffering a maintainability crisis before the transition to Windows XP; their years of bending the API to support customers (which, in the short run, did keep customers to their benefit) was making for a fairly unmaintainable mess of an API surface that then screamed under the strain when the Internet era hit and all those open, under-observed APIs became potential worm attack vectors.
- Wowfunhappy 10mo ago
  Actually, I think backwards compatibility is the reason Windows still dominates. It isn't the best OS at anything and it's actively user hostile, but if you want to run Windows apps... there are decades of Windows apps and they basically all work.
zahlman 10mo ago
> My biggest problem with the whole static typing trend is that it makes developers feel empowered to break backwards compatibility when it would be trivial to keep things working. I don't see the connection you're drawing here.
- ljm 10mo ago
  Rather, static typing empowers backwards compatibility, right? Because it lays out the contract you have to meet on the interface. No contract? No enforced compatibility.
  - dec0dedab0de 10mo ago
    It is a way to signal to other developers that your code changed, which is better than not saying anything. But it seems to make library developers more comfortable with making breaking changes. It's like they're thinking 'well it's documented, they can just change their code when they update and get errors in their type checker/linter.' When I think they should be thinking, 'I wonder what I could do to make this update as silent and easy as possible.' Of course, we all have different goals, and I'm grateful to have access to so many quality libraries for free. It's just annoying to have to spend time making changes to accommodate the aesthetic value of someone else's code.
    - ljm 10mo ago
      I think the only time I’ve ever seen this is in a JS library, where each major version bump is practically a different library altogether because it’s a complete rewrite, and these days is a wrapper around some Rust thing. Not even JS alone. I blame the enforcement of semantic versioning, as if a version of code simply had to be a sequence of meaningful numbers.
    - thayne 10mo ago
      But it also makes it easier for library developers to identify that a change is breaking. Without static types you can easily make a change you think is fine, but it ends up breaking user code because they depended on something you didn't expect. Granted, static typing doesn't completely solve that problem, there can still be changes in behavior that break things, but it is a useful tool in identifying certain classes of breaking changes.
socalgal2 10mo ago
I was hoping to spin it as an environmental concern. You change something "for reasons". If you're doing this in a popular tool/library you probably just burnt down a small forest of trees worth of energy from all of the work people will have to put in deal with it. 100s of thousands of users missed dinner with a kid or loved one because of the extra work you created. A product that would of shipped on time didn't. Things you wanted to exist didn't because 100k people were distracted dealing with your breakage.
keeperofdakeys 10mo ago
Stripe do this in a cool way. Their REST API is version based on date, and each time they change it they add a stackable compatibility layer. So your decade old code will still work. https://stripe.com/blog/api-versioning https://stripe.com/blog/api-versioning
pvtmert 10mo ago
Static Typing != Strongly Maintained Relationships. While I am happy to see types in Python and Javascript (as in Typescript) I see far more issues how people use these. In 99% of the time, people just define things as "string" or if doesn't cover, "any". (or Map/Object etc) Meanwhile most of these are Enum keys/values, or constants from dependencies. Whenever I see a `region: string` or a `stage: string`; a part of me dies. Because these need to be declared as `region: Region` or `stage: Stage`. Where the "Region" and "Stage" are proper enums or interfaces with clear values/variables/options. This helps with compile (or build) time validation and checking, preventing issues from propagating to the production (or to the runtime at all)...
bmitc 10mo ago
Isn't that arguing for keeping the maintenance cost high and also stagnating the design?
m463 10mo ago
this is the answer. No matter what others say, the pipelines are long. The delays for release, getting into a distribution, then living out its lifetime... they are significant.

jkubicek 10mo ago

> just include in the warning that it is not maintained. I'm convinced this isn't possible in practice. It doesn't matter how often you declare that something isn't maintained, the second it causes an issue with a [bigger|more important|business critical] team it suddenly needs become maintained again.

tux3 10mo ago
And here's where your business can contact me to talk about a support contract. If it's important, they'll pay. Often you find out it wasn't that important, and they're happy to figure it out.
- nisegami 10mo ago
  It sounds like you're imagining open source whereas the comment you're replying to is imagining more intra-company dependencies.
  - mbreese 10mo ago
    I think deprecation in intra-company code is a completely different beast. You either have a business case for the code or not. And if something is deprecated and a downstream project needs it, it should probably have the budget to support it (or code around the deprecation). In many ways, the decision is easier because it should be based on a business use case or budget reason.
    - zamadatix 10mo ago
      The business case is the easy part, the quagmire is in getting the different teams to agree who should support the business case, why it's more important than the business cases they wanted to spend cycles on instead, and how much of the pie supporting it takes on the budget side. Less so when the place is small enough everyone knows everyone's name, more so when it's large enough they really don't care what your business case is much even though it'd be 10x easier to support from their side instead of another.
      - spockz 10mo ago
        Oh. But that is a solved problem. The users of the library just copy the code from before the deprecation and then stick it in their codebase not to be maintained anymore. Problem solved. /s
taeric 10mo ago
I don't know that I see why/how this is a problem? You would do the same with any other thing in your life? More, in many things, we have actively decided not to do something anymore, and also highly suggest people not mess with older things that did use it. See asbestos. Removing it from a building is not cheap and can be very dangerous.
dietr1ch 10mo ago
It also keeps slowing down development as getting a green global compile will make you still update "deprecated" functions that face breaking API changes.
locknitpicker 10mo ago
> I'm convinced this isn't possible in practice. I don't agree. Some programming languages started supporting a deprecated/obsolete tagging mechanism that is designed to trigger warnings in downstream dependencies featuring a custom message. These are one-liners that change nothing in the code. Anyone who cares about deprecating something has the low-level mechanisms to do so.
- jkubicek 10mo ago
  For sure, but for this to work you need someone downstream to notice those messages and prioritize the work to migrate off the deprecated code paths. Some teams will respond, but many won't. No matter how loudly you declare that the code is deprecated, you'll still have people using it up to the point it stops working. It's far better to plan the removal of the code (and the inevitable breaking of downstream users systems) on your own schedule than to let entropy surprise you at some random point in the future.
  - locknitpicker 10mo ago
    > For sure, but for this to work you need someone downstream to notice those messages and prioritize the work to migrate off the deprecated code paths. Deprecation messages show up as compiler warnings. As a package maintainer, your job does not include taking over project management work in projects that depend on your package.

ryandrake 10mo ago

One thing I've always hated was this idea of "bitrot." That software just spontaneously stops working after time and loses backwards compatibility. Like it's some force of nature. It's not a force of nature. Bitrot is: many software developers deliberately choosing to break backward compatibility in very small ways over and over. Software written in 1995 should still work today. It's digital. It doesn't rot or fall apart. It doesn't degrade. The reason it doesn't work today is decisions that platforms and library maintainers deliberately made. Like OP. Deprecate like you mean it. That's a choice! If we want to solve bitrot, we need to stop making that choice.

jcalvinowens 10mo ago
Progress is often only possible by breaking things. It's not a choice, it's the only way forward. We have to optimize for the future being better, even if it makes the present a little worse occasionally. This is a huge reason why open source projects are often so much more successful than corporate clones: they actually iterate and innovate, something corporate america has forgotten how to do.
- mxey 10mo ago
  Actually this is the reason why Win32 is the stable ABI for Linux. https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/
  - jcalvinowens 10mo ago
    While I certainly empathize with the author of that article and respect the work they put into debugging it, this is a better explanation of that whole thing: https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash
- ryandrake 10mo ago
  It's absolutely a choice. All software can progress while preserving backward compatibility for existing users. It's not always easy, but it's never impossible.

mxey 10mo ago

> Not that it is always trivial to avoid breaking backwards compatibility, but there are so many times that it would be. In this case it was 2 functions with 1 line of code each. https://github.com/urllib3/urllib3/pull/3732/files https://github.com/urllib3/urllib3/pull/3732/files

Spivak 10mo ago
Wow. Why even remove it? It's just the thinnest wrapper around the dict and since the dict is now part of the public API these methods will work forever unmodified.

shadowgovt 10mo ago

As with all things, this can be pushed too far. Microsoft was suffering a maintainability crisis before the transition to Windows XP; their years of bending the API to support customers (which, in the short run, did keep customers to their benefit) was making for a fairly unmaintainable mess of an API surface that then screamed under the strain when the Internet era hit and all those open, under-observed APIs became potential worm attack vectors.

Wowfunhappy 10mo ago
Actually, I think backwards compatibility is the reason Windows still dominates. It isn't the best OS at anything and it's actively user hostile, but if you want to run Windows apps... there are decades of Windows apps and they basically all work.

zahlman 10mo ago

> My biggest problem with the whole static typing trend is that it makes developers feel empowered to break backwards compatibility when it would be trivial to keep things working. I don't see the connection you're drawing here.

ljm 10mo ago
Rather, static typing empowers backwards compatibility, right? Because it lays out the contract you have to meet on the interface. No contract? No enforced compatibility.
- dec0dedab0de 10mo ago
  It is a way to signal to other developers that your code changed, which is better than not saying anything. But it seems to make library developers more comfortable with making breaking changes. It's like they're thinking 'well it's documented, they can just change their code when they update and get errors in their type checker/linter.' When I think they should be thinking, 'I wonder what I could do to make this update as silent and easy as possible.' Of course, we all have different goals, and I'm grateful to have access to so many quality libraries for free. It's just annoying to have to spend time making changes to accommodate the aesthetic value of someone else's code.
  - ljm 10mo ago
    I think the only time I’ve ever seen this is in a JS library, where each major version bump is practically a different library altogether because it’s a complete rewrite, and these days is a wrapper around some Rust thing. Not even JS alone. I blame the enforcement of semantic versioning, as if a version of code simply had to be a sequence of meaningful numbers.
  - thayne 10mo ago
    But it also makes it easier for library developers to identify that a change is breaking. Without static types you can easily make a change you think is fine, but it ends up breaking user code because they depended on something you didn't expect. Granted, static typing doesn't completely solve that problem, there can still be changes in behavior that break things, but it is a useful tool in identifying certain classes of breaking changes.

socalgal2 10mo ago

I was hoping to spin it as an environmental concern. You change something "for reasons". If you're doing this in a popular tool/library you probably just burnt down a small forest of trees worth of energy from all of the work people will have to put in deal with it. 100s of thousands of users missed dinner with a kid or loved one because of the extra work you created. A product that would of shipped on time didn't. Things you wanted to exist didn't because 100k people were distracted dealing with your breakage.

keeperofdakeys 10mo ago

Stripe do this in a cool way. Their REST API is version based on date, and each time they change it they add a stackable compatibility layer. So your decade old code will still work. https://stripe.com/blog/api-versioning https://stripe.com/blog/api-versioning

pvtmert 10mo ago

Static Typing != Strongly Maintained Relationships. While I am happy to see types in Python and Javascript (as in Typescript) I see far more issues how people use these. In 99% of the time, people just define things as "string" or if doesn't cover, "any". (or Map/Object etc) Meanwhile most of these are Enum keys/values, or constants from dependencies. Whenever I see a `region: string` or a `stage: string`; a part of me dies. Because these need to be declared as `region: Region` or `stage: Stage`. Where the "Region" and "Stage" are proper enums or interfaces with clear values/variables/options. This helps with compile (or build) time validation and checking, preventing issues from propagating to the production (or to the runtime at all)...

bmitc 10mo ago

Isn't that arguing for keeping the maintenance cost high and also stagnating the design?

m463 10mo ago

this is the answer. No matter what others say, the pipelines are long. The delays for release, getting into a distribution, then living out its lifetime... they are significant.