3 ms·

I think the point is that if e.g. v7 removes a certain method, but the replacement is already available in v6, you can simply keep using v6 while updating your

I think the point is that if e.g. v7 removes a certain method, but the replacement is already available in v6, you can simply keep using v6 while updating your code to use the new method. By doing all this work on top of v6, upgrading to v7 becomes as simple as 'flipping the switch', and reverting it if issues do arise also becomes trivial. But yes, I can definitely imagine cases where trying to apply this method leads to a chicken-and-egg problem.

alias_neo 3y ago
Like the person you replied to, the example makes no sense to me. I don't program in Rails, but, in the languages that I do/have I don't recall a situation where it was _likely_ that a function or API that replaces something deprecated in an older version, was already available in that older version. The only case I can think of, that happens regularly, is that something would be deprecated and marked as such, with a replacement available at the point of deprecation. That deprecated usage should be replaced before it is removed; and if we're talking about skipping multiple major versions over a long period, the replacement likely didn't exist in the older version, so this method still wouldn't work.
- twic 3y ago
  The replacement is almost always available at the time of deprecation. Old things get deprecated precisely because there is a replacement.
  - alias_neo 3y ago
    Of course. I think you and the other commenter missed my point. If you go from version 4 (say), to version 7 (say,several years later), something could have been deprecated in 4/5 and removed entirely in 6/7, you've missed the transition period between the thing being deprecated and it being removed entirely. There's no way you're going to use the method in OP to "fix" all of the problems you'll encounter going from 4 all the way to 7 without just going to 7 and fixing everything that's broken.
    - murkt 3y ago
      There sure is a way to use the method to go from 4 all the way to 7. Just some of the fixes would be to change Rails version to 5 and 6. Author even said that it’s not a dogmatic thing, there is no point in interpreting it that way, just because OP does not include a couple of sentences on “you totally should upgrade to version 5 before going to 7”. It’s implied.
  - marcosdumay 3y ago
    You and the GP talking in universals... It's amazing that exist people whose personal experience alone isn't enough to think that way. But well, just to be clear, no all libraries do not agree on any way of managing updates.
- Anderkent 3y ago
  >That deprecated usage should be replaced before it is removed; and if we're talking about skipping multiple major versions over a long period, the replacement likely didn't exist in the older version, so this method still wouldn't work. the answer to that problem in this approach is to do multiple step upgrades, rather than skipping serious frameworks/languages do not remove methods in the same version that introduces a replacement, that's the point of having a deprecation mechanism in the first place
  - alias_neo 3y ago
    > the answer to that problem in this approach is to do multiple step upgrades, rather than skipping That's what I said > That deprecated usage (of the thing being deprecated) should be replaced (in your code, with the thing that replaced it, in the language/library) before it (the deprecated thing in the language/library) is removed (from the language/library); The example in OP was that they were upgrading major versions after-the-fact, so they've missed the transition period (say, 2 major versions, after which deprecations are removed). In my experience it has often not been beneficial to try and upgrade through multiple versions after the fact, when instead a big-bang update provides opportunities to improve the overall structure and quality of the code, because those things that were deprecated were done for a reason, and the thing being upgraded may have improved significantly in structure, usage, performance, etc in that time.

alias_neo 3y ago

Like the person you replied to, the example makes no sense to me. I don't program in Rails, but, in the languages that I do/have I don't recall a situation where it was _likely_ that a function or API that replaces something deprecated in an older version, was already available in that older version. The only case I can think of, that happens regularly, is that something would be deprecated and marked as such, with a replacement available at the point of deprecation. That deprecated usage should be replaced before it is removed; and if we're talking about skipping multiple major versions over a long period, the replacement likely didn't exist in the older version, so this method still wouldn't work.

twic 3y ago
The replacement is almost always available at the time of deprecation. Old things get deprecated precisely because there is a replacement.
- alias_neo 3y ago
  Of course. I think you and the other commenter missed my point. If you go from version 4 (say), to version 7 (say,several years later), something could have been deprecated in 4/5 and removed entirely in 6/7, you've missed the transition period between the thing being deprecated and it being removed entirely. There's no way you're going to use the method in OP to "fix" all of the problems you'll encounter going from 4 all the way to 7 without just going to 7 and fixing everything that's broken.
  - murkt 3y ago
    There sure is a way to use the method to go from 4 all the way to 7. Just some of the fixes would be to change Rails version to 5 and 6. Author even said that it’s not a dogmatic thing, there is no point in interpreting it that way, just because OP does not include a couple of sentences on “you totally should upgrade to version 5 before going to 7”. It’s implied.
- marcosdumay 3y ago
  You and the GP talking in universals... It's amazing that exist people whose personal experience alone isn't enough to think that way. But well, just to be clear, no all libraries do not agree on any way of managing updates.
Anderkent 3y ago
>That deprecated usage should be replaced before it is removed; and if we're talking about skipping multiple major versions over a long period, the replacement likely didn't exist in the older version, so this method still wouldn't work. the answer to that problem in this approach is to do multiple step upgrades, rather than skipping serious frameworks/languages do not remove methods in the same version that introduces a replacement, that's the point of having a deprecation mechanism in the first place
- alias_neo 3y ago
  > the answer to that problem in this approach is to do multiple step upgrades, rather than skipping That's what I said > That deprecated usage (of the thing being deprecated) should be replaced (in your code, with the thing that replaced it, in the language/library) before it (the deprecated thing in the language/library) is removed (from the language/library); The example in OP was that they were upgrading major versions after-the-fact, so they've missed the transition period (say, 2 major versions, after which deprecations are removed). In my experience it has often not been beneficial to try and upgrade through multiple versions after the fact, when instead a big-bang update provides opportunities to improve the overall structure and quality of the code, because those things that were deprecated were done for a reason, and the thing being upgraded may have improved significantly in structure, usage, performance, etc in that time.