As I think I previously mentioned, there is an incompatibility with rails 1.2.1 and sqlite3 3.3.8. see: http://weblog.rubyonrails.org/2007/1/29/using-sqlite3-with-rails and: http://weblog.rubyonrails.org/2007/2/6/rails-1-2-2-sqlite3-gems- singular-resources Sqlite is now at 3.3.13. Because of this, if a developer is trying to create a patch for rspec_on_rails, he will have one of the following two problems (if he is using sqlite): 1. the rails 1.2.1 specs will fail, if sqlite > 3.3.7 2. the rails 1.2.2 and greater will fail if sqlite is < 3.3.8. This renders running all of the specs as impossible with sqlite, doesn''t it? Either way, there should be *something* in the docs about it. Let me know what you guys think. Scott
On 3/27/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > As I think I previously mentioned, there is an incompatibility with > rails 1.2.1 and sqlite3 3.3.8. > > see: http://weblog.rubyonrails.org/2007/1/29/using-sqlite3-with-rails > and: http://weblog.rubyonrails.org/2007/2/6/rails-1-2-2-sqlite3-gems- > singular-resources > > Sqlite is now at 3.3.13. > > Because of this, if a developer is trying to create a patch for > rspec_on_rails, he will have one of the following two problems (if he > is using sqlite): > > 1. the rails 1.2.1 specs will fail, if sqlite > 3.3.7 > 2. the rails 1.2.2 and greater will fail if sqlite is < 3.3.8. > > This renders running all of the specs as impossible with sqlite, > doesn''t it? >Maybe it''s time to retire RSpec''s support for Rails pre 1.2.2? WDYT?> Either way, there should be *something* in the docs about it. Let > me know what you guys think. > > Scott > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
> > Maybe it''s time to retire RSpec''s support for Rails pre 1.2.2? > > WDYT?It doesn''t sound crazy to me. I''ve been running edge rails for a while now, and 1.2.2 + are just bug fixes to 1.2.1...so, I''m in favour of it. Anyone with any strong opinions on the other end? Scott
On Mar 27, 2007, at 6:34 AM, Scott Taylor wrote:>> >> Maybe it''s time to retire RSpec''s support for Rails pre 1.2.2? >> >> WDYT?Is there much pre-1.2.2 code scattered around rspec? Scott
M. Edward (Ed) Borasky
2007-Mar-27 14:04 UTC
[rspec-users] sqlite3 and rspec_on_rails tests
aslak hellesoy wrote:> On 3/27/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > >> As I think I previously mentioned, there is an incompatibility with >> rails 1.2.1 and sqlite3 3.3.8. >> >> see: http://weblog.rubyonrails.org/2007/1/29/using-sqlite3-with-rails >> and: http://weblog.rubyonrails.org/2007/2/6/rails-1-2-2-sqlite3-gems- >> singular-resources >> >> Sqlite is now at 3.3.13. >> >> Because of this, if a developer is trying to create a patch for >> rspec_on_rails, he will have one of the following two problems (if he >> is using sqlite): >> >> 1. the rails 1.2.1 specs will fail, if sqlite > 3.3.7 >> 2. the rails 1.2.2 and greater will fail if sqlite is < 3.3.8. >> >> This renders running all of the specs as impossible with sqlite, >> doesn''t it? >> >> > > Maybe it''s time to retire RSpec''s support for Rails pre 1.2.2? > > WDYT? >Well, in the case of commercial projects, there''s usually strong pressure from the vendor to minimize vendor support costs by only supporting the latest general release version and only one older one. However, since their stuff costs money, a lot of customers will attempt to keep more ancient technology alive as long as possible. But in a "free" world, there hardly seems to be any reason to support versions older than general release. Maybe you''d want to support general release minus one. So my vote is to do what makes life easier for RSpec, and if that means support only 1.2.2, do it. Then again, I run testing systems anyhow -- I don''t think I have much "general release" level code on my boxes. :) -- M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P) http://borasky-research.blogspot.com/ If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
On 3/27/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > On Mar 27, 2007, at 6:34 AM, Scott Taylor wrote: > > >> > >> Maybe it''s time to retire RSpec''s support for Rails pre 1.2.2? > >> > >> WDYT? > > Is there much pre-1.2.2 code scattered around rspec? >Not much, but we run the spec suite for Spec::Rails against 1.1.6, 1.2.1, 1.2.2, 1.2.3 and edge. Aslak> Scott > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On 3/27/07, M. Edward (Ed) Borasky <znmeb at cesmail.net> wrote:> aslak hellesoy wrote:...> > Maybe it''s time to retire RSpec''s support for Rails pre 1.2.2? > > > > WDYT?...> But in a "free" world, there hardly seems to be any reason to support > versions older than general release. Maybe you''d want to support general > release minus one.Well, even in the free software world, although the costs of buying upgrades are mitigated, there are still issues of stability and QA, as well as changing APIs and environments. Notice how Ubuntu Dapper will be supported for up to 5 years, even though 10 more editions of Ubuntu will have been released by it''s end of support (and most of them will only be supported for 18 months). Granted, having good test/spec coverage and a good quality process and developers who keep their code clean and keep abreast of current "best practices" should enable one to upgrade quickly... but it might still take some time. And there are the strategic concerns to worry about: when my company upgrades all of our apps to Rails 1.2, we *will* need to change some code that currently works in order to make it work under 1.2. This is not impossible, or even particularly difficult, but it will take a little bit of time (there is an opportunity cost), and it might not be wise to do right before a major release. (In fact, one of our apps just had a major release and won''t have another for a little while, and I''m working on cleaning up the trunk to work under 1.2 right now.) All of that said... I think it would be best to claim support for only the latest release, one previous minor release, and one previous major release: currently 1.1.6, 1.2.2, and 1.2.3. But if the cost of supporting the older releases is too high, then I would understand if you dropped support for 1.1.6 in newer releases of Spec::Rails. My company will eventually catch up. -- Nick
Since this is really a problem with rails + sqlite, maybe we should make rspec''s build depend on mysql and remove support for running the tests through sqlite ? Scott On Mar 28, 2007, at 1:40 PM, nicholas a. evans wrote:> On 3/27/07, M. Edward (Ed) Borasky <znmeb at cesmail.net> wrote: >> aslak hellesoy wrote: > ... >>> Maybe it''s time to retire RSpec''s support for Rails pre 1.2.2? >>> >>> WDYT? > ... >> But in a "free" world, there hardly seems to be any reason to support >> versions older than general release. Maybe you''d want to support >> general >> release minus one. > > Well, even in the free software world, although the costs of buying > upgrades are mitigated, there are still issues of stability and QA, as > well as changing APIs and environments. Notice how Ubuntu Dapper will > be supported for up to 5 years, even though 10 more editions of Ubuntu > will have been released by it''s end of support (and most of them will > only be supported for 18 months). > > Granted, having good test/spec coverage and a good quality process and > developers who keep their code clean and keep abreast of current "best > practices" should enable one to upgrade quickly... but it might still > take some time. And there are the strategic concerns to worry about: > when my company upgrades all of our apps to Rails 1.2, we *will* need > to change some code that currently works in order to make it work > under 1.2. This is not impossible, or even particularly difficult, > but it will take a little bit of time (there is an opportunity cost), > and it might not be wise to do right before a major release. (In > fact, one of our apps just had a major release and won''t have another > for a little while, and I''m working on cleaning up the trunk to work > under 1.2 right now.) > > All of that said... I think it would be best to claim support for only > the latest release, one previous minor release, and one previous major > release: currently 1.1.6, 1.2.2, and 1.2.3. But if the cost of > supporting the older releases is too high, then I would understand if > you dropped support for 1.1.6 in newer releases of Spec::Rails. My > company will eventually catch up. > > -- > Nick > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On 3/28/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > > Since this is really a problem with rails + sqlite, maybe we should > make rspec''s build depend on mysql and remove support for running the > tests through sqlite ?-1 SQLite is the only thing I bother to install on my development boxes these days. I shouldn''t have to go install another database system to be able to contribute to the project. Setup a cruisecontrol box with all of the databases if you''re worried about code being applied to trunk that isn''t backwards compatible. Supporting 1.2.2 would be fine with me. -- Josh Knowles joshknowles at gmail.com http://joshknowles.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070328/f6d51c32/attachment.html
On Mar 29, 2007, at 1:37 AM, Josh Knowles wrote:> > > On 3/28/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > Since this is really a problem with rails + sqlite, maybe we should > make rspec''s build depend on mysql and remove support for running the > tests through sqlite ? > > > -1 > > SQLite is the only thing I bother to install on my development > boxes these days. I shouldn''t have to go install another database > system to be able to contribute to the project. Setup a > cruisecontrol box with all of the databases if you''re worried about > code being applied to trunk that isn''t backwards compatible. > > Supporting 1.2.2 would be fine with me.Well, as it stands now you can''t even use sqlite! So, something must be done, eventually. Maybe for now we should just add a note to the docs about this, and maybe when edge rails becomes a version release it will be time to drop support for rails < 1.2.2 Scott
I Tinyurl''d the singular resources link http://tinyurl.com/2y8jmk And to view with confidence: http://preview.tinyurl.com/2y8jmk Ed On 3/27/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > As I think I previously mentioned, there is an incompatibility with > rails 1.2.1 and sqlite3 3.3.8. > > see: http://weblog.rubyonrails.org/2007/1/29/using-sqlite3-with-rails > and: http://weblog.rubyonrails.org/2007/2/6/rails-1-2-2-sqlite3-gems- > singular-resources > > Sqlite is now at 3.3.13. > > Because of this, if a developer is trying to create a patch for > rspec_on_rails, he will have one of the following two problems (if he > is using sqlite): > > 1. the rails 1.2.1 specs will fail, if sqlite > 3.3.7 > 2. the rails 1.2.2 and greater will fail if sqlite is < 3.3.8. > > This renders running all of the specs as impossible with sqlite, > doesn''t it? > > Either way, there should be *something* in the docs about it. Let > me know what you guys think. > > Scott > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Ed Howland http://greenprogrammer.blogspot.com