Something CJ noticed was that we don't really document which versions
of Ruby we support. This moves our targeted ruby versions into a feature
definition, so we can expose it in our public API documentation.
@user512 - LMK what you think as well, as it's related to the questions you were asking about drivers and such; though in this case we're using sandboxes to run checks for a particular persona.
In this case, we have two personas:
The contributor persona, whose sandbox we can use to automate checks for developers
The client persona, where we can throw different permutations of Gemfiles
Stuff to do still (that could be done later):
[x] Document the ContributorSandbox
[x] Remove the bin/setup-matrix and bin/test-matrix files
[x] Add in the other modules so we can test compensated-rails against multiple rails versions, compensated-proxy against multiple ruby versions, etc.
[ ] Maybe write a feature/ease-of-contributing.feature test that bootstraps the dev environment for the current ruby version and runs the tests?
See: https://github.com/zinc-collective/compensated/issues/81
Something CJ noticed was that we don't really document which versions of Ruby we support. This moves our targeted ruby versions into a feature definition, so we can expose it in our public API documentation.
@user512 - LMK what you think as well, as it's related to the questions you were asking about drivers and such; though in this case we're using
sandboxesto run checks for a particular persona.In this case, we have two personas:
Stuff to do still (that could be done later):
bin/setup-matrixandbin/test-matrixfilesfeature/ease-of-contributing.featuretest that bootstraps the dev environment for the current ruby version and runs the tests?