The site presents evolutions of Ruby since version 2.0 in an editorialized and well-written categorized release journal called "Ruby Evolution": https://rubyreferences.github.io/rubychanges/evolution.html
There's also individual version releases annotated as well, for example for the recent Ruby 3.2: https://rubyreferences.github.io/rubychanges/3.2.html
Note that these are not copies of the NEWS.md typically released when minor and major versions of Ruby come out. Victor specifically spent time to write more descriptive notes of what each notable change occurred over time. It's an incredible resource and we're extremely lucky to have him in our community.
There's even a changelog for this meta-changelog, which makes my little Keep a Changelog heart sing, so you can see evolutions of this site over time as well: https://rubyreferences.github.io/rubychanges/
What features in particular are you looking at in Ruby 3.0? The type system stuff seems really cool, but I haven't been hearing much about it in the wild.
2. Hire a Pwn-As-A-Service to extract data from your company from the outside
3. Tell management "I told you so"
You didn't read this here
More seriously, I think the best you can do is not expect to find happiness in a setting that you don't fully control (ie your job), accept that, and look for joy elsewhere. It might be another job, it might be another hobby. Work fewer hours.
I've stopped looking for "joy" from work. Mainly focused on finding joy with my children and other hobbies, while working as little as possible. The job is the means to that end now, rather than the end itself. They continue to pay me and it supports the things I want to do outside of work so I am "happy" enough. The work itself is also moderately interesting and a decent challenge from a domain perspective, so it's not all bad.
I feel like the best you can do unironically is the first step I outlined: ask management to formally recognize that despite your warnings, they choose cost reduction. Have a trace of that, not just in case of problems, but for yourself: it's a great reminder that as long as you aren't in charge, it can't be your problem.
That's how I upgraded from Ruby 2.4 / Rails 5.0 to Ruby 3.2 / Rails 7.0
Afaik the upgrade has been reasonably smooth, and nothing like the ruby 1.9 days.
For us, it's just incredibly hard for us to justify the effort _and_ risk. Particularly, the risk.
Most of us have been burned by a major upgrade (either here or elsewhere) where things have broken in non-obvious, hard to test ways. This is particularly problematic in the dependency chain where support is limited. Breaking issues may turn us into unexpected maintainers of key libraries.
Management.
But then again, some other times management just sucks.
Edit: The maintenance isn't a long term view btw. They are not looking at a 5-6 year window where the migration cost slowly pays off. They are worried about optimizing the next quarter.
I can’t imagine working in a place that doesn’t want to listen to its engineers or experts. (The same works the other way around too: engineers not willing to understand the business context)
It's tiring when every line of code needs a value proposition and a clear use case. Some things don't take much work to improve/maintain but are next to impossible to slap a $ value on.