On Sat, Jan 22, 2011 at 4:47 AM, David Chelimsky <dchelim...@gmail.com> wrote:
> The goal here is to set a new standard that people can count on. Right > now, many rspec users count on upgrades breaking things, which is not > exactly the sort of reliability I'd like to convey. > > I want to eliminate any perception of a binding between Rails and > RSpec releases. It's one thing to have a compatibility mapping > (rspec-2 supports rails >= 3), but it's entirely another to assume > that we need to wait for rails-4 to release rspec-3. > > As for the timing of major releases, I'm thinking more like a major > release every 6 months to a year, not 7 more in 4 months time :) And, > again, the idea is that major releases won't be quite so major. They > simply indicate that there are breaking changes in the release, and > you should upgrade to that release knowingly. > > I've found a solution that I think serves these goals well: rspec-2.5 > will add the --skip-bundler option and deprecate the implicit addition > of 'bundle exec'. It will still work as 2.4 does, but users will see a > deprecation warning explaining to use the autotest/bundler plugin or > the --skip-bundler option. When either of those options is applied, > the deprecation warning goes away. > > When it comes time to release rspec-3, rspec-autotest will be > extracted from rspec-core, the --skip-bundler will no longer do > anything, and you'll see a message saying so. At that point, you > either use the autotest/bundler plugin or not. > > Thoughts? That sounds reasonably pragmatic to me. Of course I've only had two sips of coffee this morning. <G> -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
