Hacker News Reader

Comment by alias_neo | Hacker News Reader

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.

View on HN

>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

> 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.

The replacement is almost always available at the time of deprecation. Old things get deprecated precisely because there is a replacement.

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.

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.

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.

Reply on news.ycombinator.com