Stateless Code | Create a RubyGem 96: Drop Official Support for End-of-Life Ruby 2.7 @StatelessCode | Uploaded March 2023 | Updated October 2024, 2 hours ago.
Sometimes the best way to solve a problem is to avoid it. Back in episode 89 when we ran into an issue where our build was failing on Ruby 2.7. Our fix at the time was to at least temporarily drop Ruby 2.7 from the GitHub actions build and add an item to the backlog to see if we could fix things.
In this video we tackle that backlog item. We start by taking a look at the Ruby Maintenance Branch Schedule to determine whether a fix is even worth the effort. As it turns out, Ruby 2.7 is in security maintenance only and is scheduled for End-of-Life on March 31, 2023. This video was filmed on February 22, 2023, so the Ruby version only has a little more than a month before it is unsupported.
Trying to figure out how to get the current version of RSpec to work with the 2.7 version of the gem could be time-consuming and not yield any value. We decide that the best solution, given the circumstances, is to drop support for 2.7 and bump the minimum version for future releases to 3.0. Sometimes dropping support for old versions of things is a necessary part of Technology Lifecycle Management.
Changing the minimum version requires us to upgrade the RuboCop target Ruby version, which surfaces some new violations. We had a hack in one of our shared examples that accounted for the difference in the Random class behavior between 2.7 and 3.0. With 2.7 no longer needing support, we can retire the hack and make our spec more concise.
We also no longer need to call .freeze on our regular expression literals because in Ruby 3.0 and up, they are frozen by default.
This video covers:
00:00:12 Introduction
00:01:28 Take a look at the Ruby Maintenance Branch Schedule
00:02:29 Decide to end support for Ruby 2.7 for new versions of the gem
00:03:40 Increase the required Ruby version to 3.0 in the gemspec, run `bundle install` and specs
00:04:54 Run RuboCop and fix the new violation by updating the target Ruby version
00:05:51 Remove the Ruby 2.7 specific code condition from an RSpec shared example
00:07:54 Autocorrect redundant freeze violations now that Ruby 2.7 is no longer supported
00:08:45 Review the changes in the git diff
00:09:15 Refactor the shared example we fixed earlier to be more concise
00:10:51 Commit, push, pull request
00:12:01 Create a new milestone for the 0.5 release of the gem
00:13:39 Merge pull request, close issue
#ruby #rubygems #codecast #screencast #NerdDice #DnD #roleplaying #softwaredevelopment #github #opensource #dice #tlm #ruby27 #eol
See other related StatelessCode videos:
- Create a RubyGem 89: Add Ruby 3.2 to GitHub Actions and Update RSpec to a compatible version youtu.be/kid7Cc2dzRk
Resources that we relied upon for this solution:
- Ruby Maintenance Branch Schedule ruby-lang.org/en/downloads/branches
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
Sometimes the best way to solve a problem is to avoid it. Back in episode 89 when we ran into an issue where our build was failing on Ruby 2.7. Our fix at the time was to at least temporarily drop Ruby 2.7 from the GitHub actions build and add an item to the backlog to see if we could fix things.
In this video we tackle that backlog item. We start by taking a look at the Ruby Maintenance Branch Schedule to determine whether a fix is even worth the effort. As it turns out, Ruby 2.7 is in security maintenance only and is scheduled for End-of-Life on March 31, 2023. This video was filmed on February 22, 2023, so the Ruby version only has a little more than a month before it is unsupported.
Trying to figure out how to get the current version of RSpec to work with the 2.7 version of the gem could be time-consuming and not yield any value. We decide that the best solution, given the circumstances, is to drop support for 2.7 and bump the minimum version for future releases to 3.0. Sometimes dropping support for old versions of things is a necessary part of Technology Lifecycle Management.
Changing the minimum version requires us to upgrade the RuboCop target Ruby version, which surfaces some new violations. We had a hack in one of our shared examples that accounted for the difference in the Random class behavior between 2.7 and 3.0. With 2.7 no longer needing support, we can retire the hack and make our spec more concise.
We also no longer need to call .freeze on our regular expression literals because in Ruby 3.0 and up, they are frozen by default.
This video covers:
00:00:12 Introduction
00:01:28 Take a look at the Ruby Maintenance Branch Schedule
00:02:29 Decide to end support for Ruby 2.7 for new versions of the gem
00:03:40 Increase the required Ruby version to 3.0 in the gemspec, run `bundle install` and specs
00:04:54 Run RuboCop and fix the new violation by updating the target Ruby version
00:05:51 Remove the Ruby 2.7 specific code condition from an RSpec shared example
00:07:54 Autocorrect redundant freeze violations now that Ruby 2.7 is no longer supported
00:08:45 Review the changes in the git diff
00:09:15 Refactor the shared example we fixed earlier to be more concise
00:10:51 Commit, push, pull request
00:12:01 Create a new milestone for the 0.5 release of the gem
00:13:39 Merge pull request, close issue
#ruby #rubygems #codecast #screencast #NerdDice #DnD #roleplaying #softwaredevelopment #github #opensource #dice #tlm #ruby27 #eol
See other related StatelessCode videos:
- Create a RubyGem 89: Add Ruby 3.2 to GitHub Actions and Update RSpec to a compatible version youtu.be/kid7Cc2dzRk
Resources that we relied upon for this solution:
- Ruby Maintenance Branch Schedule ruby-lang.org/en/downloads/branches
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
