Re: Changing the default version of Ruby to be 1.9
On 01/04/2012 07:17 AM, Lucas Nussbaum wrote:
Did I miss a step?
ruby-switch hasn't migrated to testing yet, you need to use unstable.
After installing unstable, i was able to run the following commands:
# apt-get install ruby1.9.1
# apt-get install ruby-switch
# ruby-switch --set ruby1.9.1
# apt-get install apt-listbugs
With those in place:
# ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
E: You need to specify a command.
Usage: apt-listbugs [options] <command> [arguments]
I don't want to guess what problems you were seeing. Can you tell me of
a specific command (complete with arguments) that doesn't work?
My current installation instructions tell people to use rvm. When
Rails 4.0 comes out, I will likely update that to say rbenv. If
there is any way that we can work together and I can make that
apt-get install, I would very much like that.
I'm not involved in rails packaging, and I've never used it. But I
mainly see rails in Debian as a prerequisite to package rails-based
applications. For developers of web apps, I'm not sure it makes sense to
install rails using apt-get.
If I read your prior post correctly, your Rails has a popcon of 2051,
which is well beyond your personal threshold of 200.
I can provide some hard data to support your statement that "There’s
also a culture (though this one has recessed a bit, I think) that it’s
perfectly fine to change APIs in incompatible ways if it makes the
software slightly better."
Edition 3 of Agile Web Development with Rails targeted Rails 2.2.2.
Here is a list of changes required in order to for people to follow
along and build the simple app described in that book or to try other
exercises if they wanted to use Rails 2.3.x instead:
Rails 3.0 was an even bigger change, and required a new edition of the
book. Rails 3.1 changes required a major update.
Things look like they are getting better. Rails 3.2 is truly a minor
update. It is too early to tell, but it looks like the switch from
Rails 3.0 to Rails 4.0 will be minor -- the primary difference will be
in dropping support for Ruby 1.8.7.
My belief is that being totally reactionary is very frustrating to
everybody involved -- to users of the packages as well as maintainers
such as yourself.
What's needed is a plan to get Ruby 2.0 (which hasn't shipped yet) and
Rails 4.0 (ditto) into Debian unstable at some point, and then to work
backwards to see what is needed to make that happen.
I've been building and testing the scenario and examples from multile
editions of my book against multiple versions of Rails running on
multiple versions of Ruby:
If we can focus on a common future, I can help by running tests,
providing patches upstream, and building packages.
- Sam Ruby