|
| 1 | +# RFC: RSpec Rails new versioning strategy |
| 2 | + |
| 3 | +Hi Folks, |
| 4 | + |
| 5 | +This RFC captures a proposal for RSpec Rails' new versioning strategy. Specifically, this represents two things: |
| 6 | +* A change in representation of what we use SemVer for, in RSpec Rails |
| 7 | +* A departure from RSpec Rails having the same versioning as RSpec's other gems (-core, -mocks, -expectations, and, internally, -support). |
| 8 | + |
| 9 | +## Need |
| 10 | + |
| 11 | +Currently, the RSpec Rails [build matrix](https://travis-ci.org/rspec/rspec-rails) |
| 12 | +has 63 entries. This permutes rubies since 1.8.7 and Rails versions since 3.0. |
| 13 | +As of right now the full build takes over an hour to run, and this makes cycling |
| 14 | +for PRs and quick iterative development very difficult. |
| 15 | + |
| 16 | +RSpec Rails's code itself also is damaged by this. Everything from the Gemfile |
| 17 | +setup[1](https://github.com/rspec/rspec-rails/blob/1d2935861c89246236b46f77de753cda5ea67d61/Gemfile) |
| 18 | +[2](https://github.com/rspec/rspec-rails/blob/1d2935861c89246236b46f77de753cda5ea67d61/Gemfile-rails-dependencies) |
| 19 | +[3](https://github.com/rspec/rspec-rails/blob/1d2935861c89246236b46f77de753cda5ea67d61/Gemfile-rspec-dependencies), |
| 20 | +to the [library code](https://github.com/rspec/rspec-rails/blob/1d2935861c89246236b46f77de753cda5ea67d61/lib/rspec/rails/configuration.rb#L128-L143), |
| 21 | +to the [test setup](https://github.com/rspec/rspec-rails/blob/1d2935861c89246236b46f77de753cda5ea67d61/Rakefile#L29-L53), |
| 22 | +to the [tests themselves](https://github.com/rspec/rspec-rails/blob/1d2935861c89246236b46f77de753cda5ea67d61/spec/rspec/rails/example/job_example_group_spec.rb) |
| 23 | +contain conditional execution based on which Rails version is currently loaded. |
| 24 | +This makes ongoing maintenance difficult, as it requires that RSpec Rails' |
| 25 | +maintainers be conscious of every Rails version that might be loaded. |
| 26 | +Acknowledging that, patches still sometimes break people's suites, due to the |
| 27 | +number of permutations of gems that can be loaded. |
| 28 | + |
| 29 | +Our need is therefore best characterised by cost of maintenance. Having to |
| 30 | +maintain several versions of Rails and Ruby costs us a lot. It makes our |
| 31 | +development slower, and forces us to write against Rails versions that most |
| 32 | +people no longer use. I want RSpec Rails development to be fast, and |
| 33 | +lightweight, much like it was when I joined the RSpec project. |
| 34 | + |
| 35 | +## Approach |
| 36 | + |
| 37 | +The approach to fix this is an adjustment of versioning strategy. RSpec Rails |
| 38 | +will still continue to maintain a SemVer strategy, that is: |
| 39 | + |
| 40 | +* Breaking changes in Majors |
| 41 | +* New features in Minors |
| 42 | +* Bug Fixes in Patchlevels |
| 43 | + |
| 44 | +For the purposes of this versioning strategy, we consider removing a Rails or |
| 45 | +Ruby version to be a breaking change. We consider adding a Ruby or Rails version |
| 46 | +to be a Minor, along with normal feature releases. |
| 47 | + |
| 48 | +The intent, however, is to change the cycle of these releases to align with |
| 49 | +Rails. Specifically, a Rails release cycle typically looks like: |
| 50 | + |
| 51 | +* Release a Major X.0, (X-2).0 is no longer supported, all but the most recent |
| 52 | + (X--1) series are unsupported, introduces deprecation warnings for many |
| 53 | + features |
| 54 | +* Release a Minor X.1, deprecation warnings from X.0 are now errors |
| 55 | +* Release a Minor X.2, new features are added, some further deprecation warnings |
| 56 | + from X.1 may now be broken. |
| 57 | + |
| 58 | +As such, RSpec Rails's new versioning strategy will be: |
| 59 | + |
| 60 | +* Release a major with any Rails Major, removing support for any newly |
| 61 | + unsupported versions of Rails, and adding support for the new major. |
| 62 | +* Release a minor with any Rails Minor, adding support for the new features |
| 63 | + * Additionally, release minors for any new RSpec features |
| 64 | +* Release patchlevels frequently, as bugfixes occur. |
| 65 | + |
| 66 | +As to the transition to this strategy: it is my intent to move to this strategy |
| 67 | +along with releasing support for Rails 5.2 for RSpec Rails, so relatively soon, |
| 68 | +dropping support for anything below Rails 4.2, and any Rubies below 2.2. This |
| 69 | +means that RSpec Rails 4.0.0 will be released within a handful of months from |
| 70 | +this RFC being accepted. |
| 71 | + |
| 72 | +I do expect this to mean that the major version of RSpec Rails will increment |
| 73 | +relatively quickly with comparison to the rest of RSpec. I do not think that is |
| 74 | +necessarily a bad thing, it does not mean that the library is unstable as such, |
| 75 | +but rather that we are tracking our dependencies accurately. |
| 76 | + |
| 77 | +Traditionally, RSpec Rails has been versioned at the same version number as |
| 78 | +RSpec. This will represent a departure from that. In order to maintain |
| 79 | +compatibility, RSpec Rails will continue to support the RSpec 3 series, and will |
| 80 | +probably add support for RSpec 4 without breaking changes. To do this, I intend |
| 81 | +to move off RSpec Rails using any private APIs from RSpec. |
| 82 | + |
| 83 | +## Benefits |
| 84 | + |
| 85 | +Execution of this strategy will greatly increase our ability to maintain RSpec, |
| 86 | +and release against modern Rails versions. While RSpec has been very stable and |
| 87 | +essentially continuously expanded Rails version support for the last few years, |
| 88 | +this has now become unsustainable and we want to take this tradeoff to best |
| 89 | +serve the needs of the community. |
| 90 | + |
| 91 | +## Competition |
| 92 | + |
| 93 | +### Do nothing |
| 94 | + |
| 95 | +If we do this, it will become deeply unsustainable for us to maintain RSpec |
| 96 | +Rails in the future. We have too many Rails versions today, and we expect the |
| 97 | +rate of Rails releases to increase as time goes on. As such, it is our intent to |
| 98 | +start dropping Rails versions inline with Rails, in order to continue to improve |
| 99 | +the RSpec Rails gem. |
| 100 | + |
| 101 | +### Keep inline versioning with RSpec |
| 102 | + |
| 103 | +RSpec has a materially different versioning need to Rails. Specifically, RSpec |
| 104 | +as of today is a mostly entirely stable library. It's development needs are |
| 105 | +largely as feature proposals occur, or as bugs are found. RSpec has no external |
| 106 | +forces pushing versioning pressure on it (other than say, ruby and bundler, |
| 107 | +which are themselves, relatively stable). This is not true of RSpec Rails, which |
| 108 | +is popular, and there is a general expectation that RSpec will work with Rails |
| 109 | +applications, as of right now, we typically lag behind a Rails release by weeks |
| 110 | +when a Rails version gets released. |
| 111 | + |
| 112 | +## Conclusions |
| 113 | + |
| 114 | +It is my intent to ship this change relatively soon, inline with Rails 5.2 |
| 115 | +support in the next few months. I really do think this represents the best |
| 116 | +future tradeoff for RSpec. If you strongly believe that dropping support for |
| 117 | +Rails versions lower than 4.2 will affect your needs, please do let us know so |
| 118 | +that we can consider the full weight of your use case. |
0 commit comments