Hi all, Since the release of rspec-2.0, I''ve been following Rubygems'' rational versioning [1] as closely as possible. Patch releases (2.4.x) have only had bug fixes, and minor releases (2.x.0) have had new features, but no (intentionally) backward incompatible changes, which should require a major (3.0) release. The autotest extension in rspec-2.0 prefixes the command it generates with ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It turns out that this is not universally helpful, so there was a request to have an opt-out. It also turns out that autotest has a bundler plugin that prefixes the command with ''bundle exec''. To use an autotest plugin, you just require it in a .autotest file in the project root. In this case: require ''autotest/bundler'' I think the right thing to do is to rely on the autotest plugin, but I also think that this would require a 3.0 release, which feels a bit grand for this situation. My question to you is: do you think this warrants a major (3.0) release, or would it be an acceptable exception to the rule (assuming proper fanfare and documentation)? [1] http://docs.rubygems.org/read/chapter/7 Cheers, David
I mean since it''s an acceptable exception, since the core parts of RSpec will still same, and autotest is somekind a "plus". Generating an major change, will make people think that RSpec was changed, with a lot of new features and etc... And it''s not the case, in current case generate a major change for 3.0 will make a lot of confusion for users. WDYT? --- Wilker L?cio http://about.me/wilkerlucio/bio Kajabi Consultant +55 81 82556600 On Tue, Jan 18, 2011 at 11:15 AM, David Chelimsky <dchelimsky at gmail.com>wrote:> Hi all, > > Since the release of rspec-2.0, I''ve been following Rubygems'' rational > versioning [1] as closely as possible. Patch releases (2.4.x) have only had > bug fixes, and minor releases (2.x.0) have had new features, but no > (intentionally) backward incompatible changes, which should require a major > (3.0) release. > > The autotest extension in rspec-2.0 prefixes the command it generates with > ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It turns > out that this is not universally helpful, so there was a request to have an > opt-out. > > It also turns out that autotest has a bundler plugin that prefixes the > command with ''bundle exec''. To use an autotest plugin, you just require it > in a .autotest file in the project root. In this case: > > require ''autotest/bundler'' > > I think the right thing to do is to rely on the autotest plugin, but I also > think that this would require a 3.0 release, which feels a bit grand for > this situation. My question to you is: do you think this warrants a major > (3.0) release, or would it be an acceptable exception to the rule (assuming > proper fanfare and documentation)? > > [1] http://docs.rubygems.org/read/chapter/7 > > Cheers, > David > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110118/f84d586f/attachment.html>
I agree with you that to create a major release for this too grand. Suitable fanfare and documentation is fine. On 18 January 2011 14:15, David Chelimsky <dchelimsky at gmail.com> wrote:> Hi all, > > Since the release of rspec-2.0, I''ve been following Rubygems'' rational > versioning [1] as closely as possible. Patch releases (2.4.x) have only had > bug fixes, and minor releases (2.x.0) have had new features, but no > (intentionally) backward incompatible changes, which should require a major > (3.0) release. > > The autotest extension in rspec-2.0 prefixes the command it generates with > ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It turns > out that this is not universally helpful, so there was a request to have an > opt-out. > > It also turns out that autotest has a bundler plugin that prefixes the > command with ''bundle exec''. To use an autotest plugin, you just require it > in a .autotest file in the project root. In this case: > > require ''autotest/bundler'' > > I think the right thing to do is to rely on the autotest plugin, but I also > think that this would require a 3.0 release, which feels a bit grand for > this situation. My question to you is: do you think this warrants a major > (3.0) release, or would it be an acceptable exception to the rule (assuming > proper fanfare and documentation)? > > [1] http://docs.rubygems.org/read/chapter/7 > > Cheers, > David > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110118/01036300/attachment.html>
On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky <dchelimsky at gmail.com> wrote:> Hi all, > > Since the release of rspec-2.0, I''ve been following Rubygems'' rational versioning [1] as closely as possible. Patch releases (2.4.x) have only had bug fixes, and minor releases (2.x.0) have had new features, but no (intentionally) backward incompatible changes, which should require a major (3.0) release. > > The autotest extension in rspec-2.0 prefixes the command it generates with ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It turns out that this is not universally helpful, so there was a request to have an opt-out. > > It also turns out that autotest has a bundler plugin that prefixes the command with ''bundle exec''. To use an autotest plugin, you just require it in a .autotest file in the project root. In this case: > > ?require ''autotest/bundler'' > > I think the right thing to do is to rely on the autotest plugin, but I also think that this would require a 3.0 release, which feels a bit grand for this situation. My question to you is: do you think this warrants a major (3.0) release, or would it be an acceptable exception to the rule (assuming proper fanfare and documentation)?Can''t something be done here as a non-breaking change? I can see two things. 1) add the requested option, I think this is optional 2) in lib/autotest/rspec2.rb def using_bundler? File.exists?(''./Gemfile'') && !defined Autotest::Bundler # and also check for the option if you decide to do #1 end -- 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
On Jan 18, 2011, at 11:08 AM, Rick DeNatale wrote:> On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >> Hi all, >> >> Since the release of rspec-2.0, I''ve been following Rubygems'' rational versioning [1] as closely as possible. Patch releases (2.4.x) have only had bug fixes, and minor releases (2.x.0) have had new features, but no (intentionally) backward incompatible changes, which should require a major (3.0) release. >> >> The autotest extension in rspec-2.0 prefixes the command it generates with ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It turns out that this is not universally helpful, so there was a request to have an opt-out. >> >> It also turns out that autotest has a bundler plugin that prefixes the command with ''bundle exec''. To use an autotest plugin, you just require it in a .autotest file in the project root. In this case: >> >> require ''autotest/bundler'' >> >> I think the right thing to do is to rely on the autotest plugin, but I also think that this would require a 3.0 release, which feels a bit grand for this situation. My question to you is: do you think this warrants a major (3.0) release, or would it be an acceptable exception to the rule (assuming proper fanfare and documentation)? > > Can''t something be done here as a non-breaking change? I can see two things. > > 1) add the requested option, I think this is optional > > 2) in lib/autotest/rspec2.rb > > def using_bundler? > File.exists?(''./Gemfile'') && !defined Autotest::Bundler # and > also check for the option if you decide to do #1 > endI actually did implement a --skip-bundler option (not yet released), but it has to be passed like this: autotest -- --skip-bundler Considering that this is a total hack, and that I''d be removing it at the next major release anyway, I really don''t want to introduce a hack on top of a hack. I''d sooner do a 3.0 release now.> -- > 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Tue, Jan 18, 2011 at 1:31 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> > On Jan 18, 2011, at 11:08 AM, Rick DeNatale wrote: > >> On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >>> Hi all, >>> >>> Since the release of rspec-2.0, I''ve been following Rubygems'' rational versioning [1] as closely as possible. Patch releases (2.4.x) have only had bug fixes, and minor releases (2.x.0) have had new features, but no (intentionally) backward incompatible changes, which should require a major (3.0) release. >>> >>> The autotest extension in rspec-2.0 prefixes the command it generates with ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It turns out that this is not universally helpful, so there was a request to have an opt-out. >>> >>> It also turns out that autotest has a bundler plugin that prefixes the command with ''bundle exec''. To use an autotest plugin, you just require it in a .autotest file in the project root. In this case: >>> >>> ?require ''autotest/bundler'' >>> >>> I think the right thing to do is to rely on the autotest plugin, but I also think that this would require a 3.0 release, which feels a bit grand for this situation. My question to you is: do you think this warrants a major (3.0) release, or would it be an acceptable exception to the rule (assuming proper fanfare and documentation)? >> >> Can''t something be done here as a non-breaking change? ?I can see two things. >> >> 1) add the requested option, I think this is optional >> >> 2) in lib/autotest/rspec2.rb >> >> ? def using_bundler? >> ? ?File.exists?(''./Gemfile'') && !defined Autotest::Bundler ?# and >> also check for the option if you decide to do #1 >> ?end > > I actually did implement a --skip-bundler option (not yet released), but it has to be passed like this: > > autotest -- --skip-bundler > > Considering that this is a total hack, and that I''d be removing it at the next major release anyway, I really don''t want to introduce a hack on top of a hack. I''d sooner do a 3.0 release now.I''m still trying to understand what you are proposing to change, and what it breaks. I guess you are proposing that the rspec autotest extension would never prefix the rspec command with ''bundle exec'' and this would break folks using autotest with rspec who haven''t changed their .autotest file. And that you think that you should bump the whole rspec suite to version 3 because of this? I guess this is because the autotest ''extension'' isn''t really an extension, it''s in rspec-core. What about those of us using other alternatives to autotest, e.g. guard? I just looked at the guard code and changing rspec as a whole to version 3 would break guard since it checks specifically for rspec version 1 vs. 2 in order to determine whether to use ''spec'' or ''rspec'' as the base command. If you bump rspec to v3 because of this, it looks like guard users will need to freeze on rspec 2, at least until the author of guard-rspec catches up. I guess that''s OK unless the latter takes too long, and rspec continues to improve only on the version 3 branch. That probably wouldn''t happen, and if it does I could fork guard-rspec myself I guess. But if you do, I think you should also break out the autotest extension into a separate gem which is NOT required by rspec-core, much like Rails 3 broke out ''most-favored'' things like Test::Unit and put alternatives like, say RSpec, and Cucumber on more of an equal footing. -- 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
On Jan 19, 2011, at 6:48 AM, Rick DeNatale wrote:> On Tue, Jan 18, 2011 at 1:31 PM, David Chelimsky <dchelimsky at gmail.com> wrote: >> >> On Jan 18, 2011, at 11:08 AM, Rick DeNatale wrote: >> >>> On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >>>> Hi all, >>>> >>>> Since the release of rspec-2.0, I''ve been following Rubygems'' rational versioning [1] as closely as possible. Patch releases (2.4.x) have only had bug fixes, and minor releases (2.x.0) have had new features, but no (intentionally) backward incompatible changes, which should require a major (3.0) release. >>>> >>>> The autotest extension in rspec-2.0 prefixes the command it generates with ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It turns out that this is not universally helpful, so there was a request to have an opt-out. >>>> >>>> It also turns out that autotest has a bundler plugin that prefixes the command with ''bundle exec''. To use an autotest plugin, you just require it in a .autotest file in the project root. In this case: >>>> >>>> require ''autotest/bundler'' >>>> >>>> I think the right thing to do is to rely on the autotest plugin, but I also think that this would require a 3.0 release, which feels a bit grand for this situation. My question to you is: do you think this warrants a major (3.0) release, or would it be an acceptable exception to the rule (assuming proper fanfare and documentation)? >>> >>> Can''t something be done here as a non-breaking change? I can see two things. >>> >>> 1) add the requested option, I think this is optional >>> >>> 2) in lib/autotest/rspec2.rb >>> >>> def using_bundler? >>> File.exists?(''./Gemfile'') && !defined Autotest::Bundler # and >>> also check for the option if you decide to do #1 >>> end >> >> I actually did implement a --skip-bundler option (not yet released), but it has to be passed like this: >> >> autotest -- --skip-bundler >> >> Considering that this is a total hack, and that I''d be removing it at the next major release anyway, I really don''t want to introduce a hack on top of a hack. I''d sooner do a 3.0 release now. > > I''m still trying to understand what you are proposing to change, and > what it breaks. > > I guess you are proposing that the rspec autotest extension would > never prefix the rspec command with ''bundle exec'' and this would break > folks using autotest with rspec who haven''t changed their .autotest > file.Correct.> And that you think that you should bump the whole rspec suite to > version 3 because of this? I guess this is because the autotest > ''extension'' isn''t really an extension, it''s in rspec-core.Correct. And I''m trying to establish a consistent pattern in releases so people can trust that minor and patch releases won''t introduce breaking changes. This one is a bit of an outlier, and I started this thread to see what ppl thought of treating it as such, but the more I think of it, the more I''m convinced that this should not be an exception.> What about those of us using other alternatives to autotest, e.g. > guard? I just looked at the guard code and changing rspec as a whole > to version 3 would break guard since it checks specifically for rspec > version 1 vs. 2 in order to determine whether to use ''spec'' or ''rspec'' > as the base command.That''s unfortunate. Whether or not I do an rspec-3 release now, adherence to Rubygems'' rational versioning policy will likely result in an rspec-3 release in much less time than it took us to get to rspec-2. When it comes out, rspec-3 will not represent a major rewrite or significant API or functional changes. It will simply be an indicator that there are backward-incompatible changes in that release and you should accept that upgrade consciously and carefully.> If you bump rspec to v3 because of this, it looks like guard users > will need to freeze on rspec 2, at least until the author of > guard-rspec catches up. I guess that''s OK unless the latter takes too > long, and rspec continues to improve only on the version 3 branch. > That probably wouldn''t happen, and if it does I could fork guard-rspec > myself I guess.Thanks for being willing to help out. We should probably hit guard-rspec up with this now, though, so when rspec-3 does come along guard users don''t have to take a hit at that point. Do you want to drive that?> But if you do, I think you should also break out the autotest > extension into a separate gem which is NOT required by rspec-core, > much like Rails 3 broke out ''most-favored'' things like Test::Unit and > put alternatives like, say RSpec, and Cucumber on more of an equal > footing.Definitely in the plan for rspec-3: https://github.com/rspec/rspec-core/issues/issue/285. Cheers, David
On 21 January 2011 13:56, David Chelimsky <dchelimsky at gmail.com> wrote:> On Jan 19, 2011, at 6:48 AM, Rick DeNatale wrote: > > > On Tue, Jan 18, 2011 at 1:31 PM, David Chelimsky <dchelimsky at gmail.com> > wrote: > >> > >> On Jan 18, 2011, at 11:08 AM, Rick DeNatale wrote: > >> > >>> On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky <dchelimsky at gmail.com> > wrote: > >>>> Hi all, > >>>> > >>>> Since the release of rspec-2.0, I''ve been following Rubygems'' rational > versioning [1] as closely as possible. Patch releases (2.4.x) have only had > bug fixes, and minor releases (2.x.0) have had new features, but no > (intentionally) backward incompatible changes, which should require a major > (3.0) release. > >>>> > >>>> The autotest extension in rspec-2.0 prefixes the command it generates > with ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It > turns out that this is not universally helpful, so there was a request to > have an opt-out. > >>>> > >>>> It also turns out that autotest has a bundler plugin that prefixes the > command with ''bundle exec''. To use an autotest plugin, you just require it > in a .autotest file in the project root. In this case: > >>>> > >>>> require ''autotest/bundler'' > >>>> > >>>> I think the right thing to do is to rely on the autotest plugin, but I > also think that this would require a 3.0 release, which feels a bit grand > for this situation. My question to you is: do you think this warrants a > major (3.0) release, or would it be an acceptable exception to the rule > (assuming proper fanfare and documentation)? > >>> > >>> Can''t something be done here as a non-breaking change? I can see two > things. > >>> > >>> 1) add the requested option, I think this is optional > >>> > >>> 2) in lib/autotest/rspec2.rb > >>> > >>> def using_bundler? > >>> File.exists?(''./Gemfile'') && !defined Autotest::Bundler # and > >>> also check for the option if you decide to do #1 > >>> end > >> > >> I actually did implement a --skip-bundler option (not yet released), but > it has to be passed like this: > >> > >> autotest -- --skip-bundler > >> > >> Considering that this is a total hack, and that I''d be removing it at > the next major release anyway, I really don''t want to introduce a hack on > top of a hack. I''d sooner do a 3.0 release now. > > > > I''m still trying to understand what you are proposing to change, and > > what it breaks. > > > > I guess you are proposing that the rspec autotest extension would > > never prefix the rspec command with ''bundle exec'' and this would break > > folks using autotest with rspec who haven''t changed their .autotest > > file. > > Correct. > > > And that you think that you should bump the whole rspec suite to > > version 3 because of this? I guess this is because the autotest > > ''extension'' isn''t really an extension, it''s in rspec-core. > > Correct. And I''m trying to establish a consistent pattern in releases so > people can trust that minor and patch releases won''t introduce breaking > changes. This one is a bit of an outlier, and I started this thread to see > what ppl thought of treating it as such, but the more I think of it, the > more I''m convinced that this should not be an exception. > > > What about those of us using other alternatives to autotest, e.g. > > guard? I just looked at the guard code and changing rspec as a whole > > to version 3 would break guard since it checks specifically for rspec > > version 1 vs. 2 in order to determine whether to use ''spec'' or ''rspec'' > > as the base command. > > That''s unfortunate. Whether or not I do an rspec-3 release now, adherence > to Rubygems'' rational versioning policy will likely result in an rspec-3 > release in much less time than it took us to get to rspec-2. When it comes > out, rspec-3 will not represent a major rewrite or significant API or > functional changes. It will simply be an indicator that there are > backward-incompatible changes in that release and you should accept that > upgrade consciously and carefully. > > > If you bump rspec to v3 because of this, it looks like guard users > > will need to freeze on rspec 2, at least until the author of > > guard-rspec catches up. I guess that''s OK unless the latter takes too > > long, and rspec continues to improve only on the version 3 branch. > > That probably wouldn''t happen, and if it does I could fork guard-rspec > > myself I guess. > > Thanks for being willing to help out. We should probably hit guard-rspec up > with this now, though, so when rspec-3 does come along guard users don''t > have to take a hit at that point. Do you want to drive that? > > > But if you do, I think you should also break out the autotest > > extension into a separate gem which is NOT required by rspec-core, > > much like Rails 3 broke out ''most-favored'' things like Test::Unit and > > put alternatives like, say RSpec, and Cucumber on more of an equal > > footing. > > Definitely in the plan for rspec-3: > https://github.com/rspec/rspec-core/issues/issue/285. > > Cheers, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >Whilst its very noble to try and follow the ruby gems document to the letter, some consideration has to be given to the overall effect of rapidly changing major version numbers on the project. RSpec has a very large user base, a close tie in with Rails major versions, in particular the idea to Rails 3 should use RSpec 2, and a history of changing major versions very infrequently with major consequences to the vast majority of users. This I think is a fair assessment of RSpec''s context re version numbers. To move to RSpec 3, for such a small change would be completely out of character for the project. To end up in 4 months time with RSpec 9 would be very detrimental to the projects reputation. So I think the pragmatic approach is a minor release with a big caveat in the history and a big announcement on the mailing list All best Andrew -- ------------------------ Andrew Premdas blog.andrew.premdas.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110121/77beaae2/attachment-0001.html>
On Tue, Jan 18, 2011 at 11:15 AM, David Chelimsky <dchelimsky at gmail.com> wrote:> > [...] > > I think the right thing to do is to rely on the autotest plugin, but I also think that this would require a 3.0 release, which feels a bit grand for this situation. My question to you is: do you think this warrants a major (3.0) release, or would it be an acceptable exception to the rule (assuming proper fanfare and documentation)? >IMHO this case is a exception to the rule that we can live with. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
On Fri, Jan 21, 2011 at 5:13 PM, Andrew Premdas <apremdas at gmail.com> wrote:> On 21 January 2011 13:56, David Chelimsky <dchelimsky at gmail.com> wrote: >> >> On Jan 19, 2011, at 6:48 AM, Rick DeNatale wrote: >> >> > On Tue, Jan 18, 2011 at 1:31 PM, David Chelimsky <dchelimsky at gmail.com> >> > wrote: >> >> >> >> On Jan 18, 2011, at 11:08 AM, Rick DeNatale wrote: >> >> >> >>> On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky >> >>> <dchelimsky at gmail.com> wrote: >> >>>> Hi all, >> >>>> >> >>>> Since the release of rspec-2.0, I''ve been following Rubygems'' >> >>>> rational versioning [1] as closely as possible. Patch releases (2.4.x) have >> >>>> only had bug fixes, and minor releases (2.x.0) have had new features, but no >> >>>> (intentionally) backward incompatible changes, which should require a major >> >>>> (3.0) release. >> >>>> >> >>>> The autotest extension in rspec-2.0 prefixes the command it generates >> >>>> with ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It >> >>>> turns out that this is not universally helpful, so there was a request to >> >>>> have an opt-out. >> >>>> >> >>>> It also turns out that autotest has a bundler plugin that prefixes >> >>>> the command with ''bundle exec''. To use an autotest plugin, you just require >> >>>> it in a .autotest file in the project root. In this case: >> >>>> >> >>>> ?require ''autotest/bundler'' >> >>>> >> >>>> I think the right thing to do is to rely on the autotest plugin, but >> >>>> I also think that this would require a 3.0 release, which feels a bit grand >> >>>> for this situation. My question to you is: do you think this warrants a >> >>>> major (3.0) release, or would it be an acceptable exception to the rule >> >>>> (assuming proper fanfare and documentation)? >> >>> >> >>> Can''t something be done here as a non-breaking change? ?I can see two >> >>> things. >> >>> >> >>> 1) add the requested option, I think this is optional >> >>> >> >>> 2) in lib/autotest/rspec2.rb >> >>> >> >>> ? def using_bundler? >> >>> ? ?File.exists?(''./Gemfile'') && !defined Autotest::Bundler ?# and >> >>> also check for the option if you decide to do #1 >> >>> ?end >> >> >> >> I actually did implement a --skip-bundler option (not yet released), >> >> but it has to be passed like this: >> >> >> >> autotest -- --skip-bundler >> >> >> >> Considering that this is a total hack, and that I''d be removing it at >> >> the next major release anyway, I really don''t want to introduce a hack on >> >> top of a hack. I''d sooner do a 3.0 release now. >> > >> > I''m still trying to understand what you are proposing to change, and >> > what it breaks. >> > >> > I guess you are proposing that the ?rspec autotest extension would >> > never prefix the rspec command with ''bundle exec'' and this would break >> > folks using autotest with rspec who haven''t changed their .autotest >> > file. >> >> Correct. >> >> > And that you think that you should bump the whole rspec suite to >> > version 3 because of this? I guess this is because the autotest >> > ''extension'' isn''t really an extension, it''s in rspec-core. >> >> Correct. And I''m trying to establish a consistent pattern in releases so >> people can trust that minor and patch releases won''t introduce breaking >> changes. This one is a bit of an outlier, and I started this thread to see >> what ppl thought of treating it as such, but the more I think of it, the >> more I''m convinced that this should not be an exception. >> >> > What about those of us using other alternatives to autotest, e.g. >> > guard? ?I just looked at the guard code and changing rspec as a whole >> > to version 3 would break guard since it checks specifically for rspec >> > version 1 vs. 2 in order to determine whether to use ''spec'' or ''rspec'' >> > as the base command. >> >> That''s unfortunate. Whether or not I do an rspec-3 release now, adherence >> to Rubygems'' rational versioning policy will likely result in an rspec-3 >> release in much less time than it took us to get to rspec-2. When it comes >> out, rspec-3 will not represent a major rewrite or significant API or >> functional changes. It will simply be an indicator that there are >> backward-incompatible changes in that release and you should accept that >> upgrade consciously and carefully. >> >> > If you bump rspec to v3 because of this, it looks like guard users >> > will need to freeze on rspec 2, at least until the author of >> > guard-rspec catches up. ?I guess that''s OK unless the latter takes too >> > long, and rspec continues to improve only on the version 3 branch. >> > That probably wouldn''t happen, and if it does I could fork guard-rspec >> > myself I guess. >> >> Thanks for being willing to help out. We should probably hit guard-rspec >> up with this now, though, so when rspec-3 does come along guard users don''t >> have to take a hit at that point. Do you want to drive that? >> >> > But if you do, I think you should also break out the autotest >> > extension into a separate gem which is NOT required by rspec-core, >> > much like Rails 3 broke out ''most-favored'' things like Test::Unit and >> > put alternatives like, say RSpec, and Cucumber on more of an equal >> > footing. >> >> Definitely in the plan for rspec-3: >> https://github.com/rspec/rspec-core/issues/issue/285. >> >> Cheers, >> David >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > Whilst its very noble to try and follow the ruby gems document to the > letter, some consideration has to be given to the overall effect of rapidly > changing major version numbers on the project. RSpec has a very large user > base, a close tie in with Rails major versions, in particular the idea to > Rails 3 should use RSpec 2, and a history of changing major versions very > infrequently with major consequences to the vast majority of users. This I > think is a fair assessment of RSpec''s context re version numbers. To move to > RSpec 3, for such a small change would be completely out of character for > the project. To end up in 4 months time with RSpec 9 would be very > detrimental to the projects reputation. > So I think the pragmatic approach is a minor release with a big caveat in > the history and a big announcement on the mailing listThe 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?
On Fri, Jan 21, 2011 at 5:45 PM, Luis Lavena <luislavena at gmail.com> wrote:> On Tue, Jan 18, 2011 at 11:15 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >> >> [...] >> >> I think the right thing to do is to rely on the autotest plugin, but I also think that this would require a 3.0 release, which feels a bit grand for this situation. My question to you is: do you think this warrants a major (3.0) release, or would it be an acceptable exception to the rule (assuming proper fanfare and documentation)? >> > > IMHO this case is a exception to the rule that we can live with.Luis, you''re one of those early adopter types, aren''t you :) I''d like to spend some time establishing the rule before making exceptions. Per other post this thread, I think I''ve got a workable solution in place for the rspec-2.5 release. Cheers, David
On Sat, Jan 22, 2011 at 4:47 AM, David Chelimsky <dchelimsky at 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
]On 22 January 2011 09:47, David Chelimsky <dchelimsky at gmail.com> wrote:> On Fri, Jan 21, 2011 at 5:13 PM, Andrew Premdas <apremdas at gmail.com> > wrote: > > On 21 January 2011 13:56, David Chelimsky <dchelimsky at gmail.com> wrote: > >> > >> On Jan 19, 2011, at 6:48 AM, Rick DeNatale wrote: > >> > >> > On Tue, Jan 18, 2011 at 1:31 PM, David Chelimsky < > dchelimsky at gmail.com> > >> > wrote: > >> >> > >> >> On Jan 18, 2011, at 11:08 AM, Rick DeNatale wrote: > >> >> > >> >>> On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky > >> >>> <dchelimsky at gmail.com> wrote: > >> >>>> Hi all, > >> >>>> > >> >>>> Since the release of rspec-2.0, I''ve been following Rubygems'' > >> >>>> rational versioning [1] as closely as possible. Patch releases > (2.4.x) have > >> >>>> only had bug fixes, and minor releases (2.x.0) have had new > features, but no > >> >>>> (intentionally) backward incompatible changes, which should require > a major > >> >>>> (3.0) release. > >> >>>> > >> >>>> The autotest extension in rspec-2.0 prefixes the command it > generates > >> >>>> with ''bundle exec'' if it sees a ''Gemfile'' in the project root > directory. It > >> >>>> turns out that this is not universally helpful, so there was a > request to > >> >>>> have an opt-out. > >> >>>> > >> >>>> It also turns out that autotest has a bundler plugin that prefixes > >> >>>> the command with ''bundle exec''. To use an autotest plugin, you just > require > >> >>>> it in a .autotest file in the project root. In this case: > >> >>>> > >> >>>> require ''autotest/bundler'' > >> >>>> > >> >>>> I think the right thing to do is to rely on the autotest plugin, > but > >> >>>> I also think that this would require a 3.0 release, which feels a > bit grand > >> >>>> for this situation. My question to you is: do you think this > warrants a > >> >>>> major (3.0) release, or would it be an acceptable exception to the > rule > >> >>>> (assuming proper fanfare and documentation)? > >> >>> > >> >>> Can''t something be done here as a non-breaking change? I can see > two > >> >>> things. > >> >>> > >> >>> 1) add the requested option, I think this is optional > >> >>> > >> >>> 2) in lib/autotest/rspec2.rb > >> >>> > >> >>> def using_bundler? > >> >>> File.exists?(''./Gemfile'') && !defined Autotest::Bundler # and > >> >>> also check for the option if you decide to do #1 > >> >>> end > >> >> > >> >> I actually did implement a --skip-bundler option (not yet released), > >> >> but it has to be passed like this: > >> >> > >> >> autotest -- --skip-bundler > >> >> > >> >> Considering that this is a total hack, and that I''d be removing it at > >> >> the next major release anyway, I really don''t want to introduce a > hack on > >> >> top of a hack. I''d sooner do a 3.0 release now. > >> > > >> > I''m still trying to understand what you are proposing to change, and > >> > what it breaks. > >> > > >> > I guess you are proposing that the rspec autotest extension would > >> > never prefix the rspec command with ''bundle exec'' and this would break > >> > folks using autotest with rspec who haven''t changed their .autotest > >> > file. > >> > >> Correct. > >> > >> > And that you think that you should bump the whole rspec suite to > >> > version 3 because of this? I guess this is because the autotest > >> > ''extension'' isn''t really an extension, it''s in rspec-core. > >> > >> Correct. And I''m trying to establish a consistent pattern in releases so > >> people can trust that minor and patch releases won''t introduce breaking > >> changes. This one is a bit of an outlier, and I started this thread to > see > >> what ppl thought of treating it as such, but the more I think of it, the > >> more I''m convinced that this should not be an exception. > >> > >> > What about those of us using other alternatives to autotest, e.g. > >> > guard? I just looked at the guard code and changing rspec as a whole > >> > to version 3 would break guard since it checks specifically for rspec > >> > version 1 vs. 2 in order to determine whether to use ''spec'' or ''rspec'' > >> > as the base command. > >> > >> That''s unfortunate. Whether or not I do an rspec-3 release now, > adherence > >> to Rubygems'' rational versioning policy will likely result in an rspec-3 > >> release in much less time than it took us to get to rspec-2. When it > comes > >> out, rspec-3 will not represent a major rewrite or significant API or > >> functional changes. It will simply be an indicator that there are > >> backward-incompatible changes in that release and you should accept that > >> upgrade consciously and carefully. > >> > >> > If you bump rspec to v3 because of this, it looks like guard users > >> > will need to freeze on rspec 2, at least until the author of > >> > guard-rspec catches up. I guess that''s OK unless the latter takes too > >> > long, and rspec continues to improve only on the version 3 branch. > >> > That probably wouldn''t happen, and if it does I could fork guard-rspec > >> > myself I guess. > >> > >> Thanks for being willing to help out. We should probably hit guard-rspec > >> up with this now, though, so when rspec-3 does come along guard users > don''t > >> have to take a hit at that point. Do you want to drive that? > >> > >> > But if you do, I think you should also break out the autotest > >> > extension into a separate gem which is NOT required by rspec-core, > >> > much like Rails 3 broke out ''most-favored'' things like Test::Unit and > >> > put alternatives like, say RSpec, and Cucumber on more of an equal > >> > footing. > >> > >> Definitely in the plan for rspec-3: > >> https://github.com/rspec/rspec-core/issues/issue/285. > >> > >> Cheers, > >> David > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-users > > > > Whilst its very noble to try and follow the ruby gems document to the > > letter, some consideration has to be given to the overall effect of > rapidly > > changing major version numbers on the project. RSpec has a very large > user > > base, a close tie in with Rails major versions, in particular the idea to > > Rails 3 should use RSpec 2, and a history of changing major versions very > > infrequently with major consequences to the vast majority of users. This > I > > think is a fair assessment of RSpec''s context re version numbers. To move > to > > RSpec 3, for such a small change would be completely out of character for > > the project. To end up in 4 months time with RSpec 9 would be very > > detrimental to the projects reputation. > > So I think the pragmatic approach is a minor release with a big caveat in > > the history and a big announcement on the mailing list > > 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. >Of course, and I wasn''t suggesting that rspec3 should wait for rails4.>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. > > My concern is that people (especially project owners and people furtheraway from the project) seeing RSpec moving quickly to 3, 4, 5 will judge the project unstable and think that each change will involve a similar amount of work as moving from rspec1 to 2, or even Rails 2.x to 3.x. This would be a good (in innaccurate) argument for choosing a more ''stable'' test tool. A major release every 6 months to a year seems reasonable, but I''m not convinced you could keep to this if this particular change and changes like it caused a major release. 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. >The add an option and a deprecation warning approach seems an excellent compromise to prepare for a more permanent solution in 3.0. Perhaps there is a pattern here to be applied to similar changes, thus giving advanced users time to use the new functionality in anger, and get feedback over a period of time. All best Andrew> > 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? > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- ------------------------ Andrew Premdas blog.andrew.premdas.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110123/7a4caf12/attachment.html>
On Jan 22, 2011, at 6:50 PM, Andrew Premdas wrote:> ]On 22 January 2011 09:47, David Chelimsky <dchelimsky at gmail.com> wrote: > On Fri, Jan 21, 2011 at 5:13 PM, Andrew Premdas <apremdas at gmail.com> wrote: > > On 21 January 2011 13:56, David Chelimsky <dchelimsky at gmail.com> wrote: > >> > >> On Jan 19, 2011, at 6:48 AM, Rick DeNatale wrote: > >> > >> > On Tue, Jan 18, 2011 at 1:31 PM, David Chelimsky <dchelimsky at gmail.com> > >> > wrote: > >> >> > >> >> On Jan 18, 2011, at 11:08 AM, Rick DeNatale wrote: > >> >> > >> >>> On Tue, Jan 18, 2011 at 9:15 AM, David Chelimsky > >> >>> <dchelimsky at gmail.com> wrote: > >> >>>> Hi all, > >> >>>> > >> >>>> Since the release of rspec-2.0, I''ve been following Rubygems'' > >> >>>> rational versioning [1] as closely as possible. Patch releases (2.4.x) have > >> >>>> only had bug fixes, and minor releases (2.x.0) have had new features, but no > >> >>>> (intentionally) backward incompatible changes, which should require a major > >> >>>> (3.0) release. > >> >>>> > >> >>>> The autotest extension in rspec-2.0 prefixes the command it generates > >> >>>> with ''bundle exec'' if it sees a ''Gemfile'' in the project root directory. It > >> >>>> turns out that this is not universally helpful, so there was a request to > >> >>>> have an opt-out. > >> >>>> > >> >>>> It also turns out that autotest has a bundler plugin that prefixes > >> >>>> the command with ''bundle exec''. To use an autotest plugin, you just require > >> >>>> it in a .autotest file in the project root. In this case: > >> >>>> > >> >>>> require ''autotest/bundler'' > >> >>>> > >> >>>> I think the right thing to do is to rely on the autotest plugin, but > >> >>>> I also think that this would require a 3.0 release, which feels a bit grand > >> >>>> for this situation. My question to you is: do you think this warrants a > >> >>>> major (3.0) release, or would it be an acceptable exception to the rule > >> >>>> (assuming proper fanfare and documentation)? > >> >>> > >> >>> Can''t something be done here as a non-breaking change? I can see two > >> >>> things. > >> >>> > >> >>> 1) add the requested option, I think this is optional > >> >>> > >> >>> 2) in lib/autotest/rspec2.rb > >> >>> > >> >>> def using_bundler? > >> >>> File.exists?(''./Gemfile'') && !defined Autotest::Bundler # and > >> >>> also check for the option if you decide to do #1 > >> >>> end > >> >> > >> >> I actually did implement a --skip-bundler option (not yet released), > >> >> but it has to be passed like this: > >> >> > >> >> autotest -- --skip-bundler > >> >> > >> >> Considering that this is a total hack, and that I''d be removing it at > >> >> the next major release anyway, I really don''t want to introduce a hack on > >> >> top of a hack. I''d sooner do a 3.0 release now. > >> > > >> > I''m still trying to understand what you are proposing to change, and > >> > what it breaks. > >> > > >> > I guess you are proposing that the rspec autotest extension would > >> > never prefix the rspec command with ''bundle exec'' and this would break > >> > folks using autotest with rspec who haven''t changed their .autotest > >> > file. > >> > >> Correct. > >> > >> > And that you think that you should bump the whole rspec suite to > >> > version 3 because of this? I guess this is because the autotest > >> > ''extension'' isn''t really an extension, it''s in rspec-core. > >> > >> Correct. And I''m trying to establish a consistent pattern in releases so > >> people can trust that minor and patch releases won''t introduce breaking > >> changes. This one is a bit of an outlier, and I started this thread to see > >> what ppl thought of treating it as such, but the more I think of it, the > >> more I''m convinced that this should not be an exception. > >> > >> > What about those of us using other alternatives to autotest, e.g. > >> > guard? I just looked at the guard code and changing rspec as a whole > >> > to version 3 would break guard since it checks specifically for rspec > >> > version 1 vs. 2 in order to determine whether to use ''spec'' or ''rspec'' > >> > as the base command. > >> > >> That''s unfortunate. Whether or not I do an rspec-3 release now, adherence > >> to Rubygems'' rational versioning policy will likely result in an rspec-3 > >> release in much less time than it took us to get to rspec-2. When it comes > >> out, rspec-3 will not represent a major rewrite or significant API or > >> functional changes. It will simply be an indicator that there are > >> backward-incompatible changes in that release and you should accept that > >> upgrade consciously and carefully. > >> > >> > If you bump rspec to v3 because of this, it looks like guard users > >> > will need to freeze on rspec 2, at least until the author of > >> > guard-rspec catches up. I guess that''s OK unless the latter takes too > >> > long, and rspec continues to improve only on the version 3 branch. > >> > That probably wouldn''t happen, and if it does I could fork guard-rspec > >> > myself I guess. > >> > >> Thanks for being willing to help out. We should probably hit guard-rspec > >> up with this now, though, so when rspec-3 does come along guard users don''t > >> have to take a hit at that point. Do you want to drive that? > >> > >> > But if you do, I think you should also break out the autotest > >> > extension into a separate gem which is NOT required by rspec-core, > >> > much like Rails 3 broke out ''most-favored'' things like Test::Unit and > >> > put alternatives like, say RSpec, and Cucumber on more of an equal > >> > footing. > >> > >> Definitely in the plan for rspec-3: > >> https://github.com/rspec/rspec-core/issues/issue/285. > >> > >> Cheers, > >> David > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-users > > > > Whilst its very noble to try and follow the ruby gems document to the > > letter, some consideration has to be given to the overall effect of rapidly > > changing major version numbers on the project. RSpec has a very large user > > base, a close tie in with Rails major versions, in particular the idea to > > Rails 3 should use RSpec 2, and a history of changing major versions very > > infrequently with major consequences to the vast majority of users. This I > > think is a fair assessment of RSpec''s context re version numbers. To move to > > RSpec 3, for such a small change would be completely out of character for > > the project. To end up in 4 months time with RSpec 9 would be very > > detrimental to the projects reputation. > > So I think the pragmatic approach is a minor release with a big caveat in > > the history and a big announcement on the mailing list > > 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. > > Of course, and I wasn''t suggesting that rspec3 should wait for rails4. > > 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. > > My concern is that people (especially project owners and people further away from the project) seeing RSpec moving quickly to 3, 4, 5 will judge the project unstable and think that each change will involve a similar amount of work as moving from rspec1 to 2, or even Rails 2.x to 3.x. This would be a good (in innaccurate) argument for choosing a more ''stable'' test tool.If breaking changes only happen in major releases, and that turns some people away, then so be it. I''m hopeful that the ability to rely on minor releases not breaking things will outweigh that concern for most. I''ll soon be posting a more detailed explanation of the release policy on http://relishapp.com/rspec, and blogging about it long before there is a 3.0 release. If people read that (or fail to read it) and still decide that this policy is a sign of instability, there''s not much that I can do about that.> A major release every 6 months to a year seems reasonable, but I''m not convinced you could keep to this if this particular change and changes like it caused a major release.I''m not saying there would be a release every time a change like this came up. There will be a major release once enough of them pile up that it makes sense to clean house.> 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. > > The add an option and a deprecation warning approach seems an excellent compromise to prepare for a more permanent solution in 3.0. Perhaps there is a pattern here to be applied to similar changes,That''s the idea.> thus giving advanced users time to use the new functionality in anger, and get feedback over a period of time.Early feedback would definitely be an added benefit. Cheers, David> > All best > > Andrew > > 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. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110122/4c65f4af/attachment-0001.html>