Ruby 1.9 isn't intended to production. It's a transitional release that aims
to stabilize the code base to 2.0 release.
Probably it can't be on debian stable version!
Regards,
Luiz Vitor.
On Tue, Feb 3, 2009 at 12:24 PM, Lucas Nussbaum <lu...@lucas-nussbaum.net>wrote:
> [ M-F-T set to debian-ruby@ ]
>
> Hi,
>
> We (Ruby interpreter maintainers) would like to hear the opinion of
> other people interested in Ruby on our proposed plans for Ruby in
> squeeze.
>
> After discussion will have happened on debian-ruby@, we will also ask
> the release team.
>
> Current status
> ==============
> In lenny, we will ship two versions of the Ruby interpreter:
>
> Ruby 1.8 (the "stable" version) (package: ruby1.8 1.8.7.72-3)
>
> Ruby 1.9.0 (the "new stable" version) (package: ruby1.9 1.9.0.2-8)
>
> Both ruby1.8 and ruby1.9 source packages build several binary packages:
> - ruby1.n (with n=8,9) (arch: any, contains the interpreter binary
> and other things, very small)
> - libruby1.n (arch: any, contains /usr/lib/libruby1.n.so.1.n and
> most of the stdlib)
> - ruby1.n-dev (arch: any, provides headers, etc)
> - irb1.n, ri1.n, rdoc1.n (arch: all, provide developement tools)
> - some shared libs, such as libdbm-ruby1.n, libgdbm-ruby1.n,
> libopenssl-ruby1.n, etc. (arch: any, split out libruby1.n to
> remove some dependencies)
>
> Packages currently depend either on ruby1.n or libruby1.n when they
> need ruby 1.n.
>
> Ruby 1.8 plans
> ==============
> It is not clear yet whether we will ship a ruby1.8 version in squeeze.
> It will depend on how fast Ruby 1.9 is adopted. It is highly
> possible that we decide to remove Ruby 1.8 from squeeze quite late in the
> release process, to avoid supporting it in a stable release.
>
> In all cases, we don't plan to change the way ruby 1.8 is packaged.
>
> Ruby 1.9 plans
> ==============
> Ruby 1.9 is a different story. Upstream decided to version the API,
> and add a third digit to the library search path:
> /usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
> Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
> released upstream soon) won't be simple.
>
> We have two solutions:
> (A) allow for several ruby 1.9.{x,y} versions to be in the archive and
> installed at the same time, and do not support upgrades between them.
> (B) allow only one ruby1.9.{x,y} version to be in a given suite,
> provide upgrades between 1.9.{x,y}, and do mass-transitions of all
> ruby libs when a new 1.9.z is released. (ruby would have to migrate
> together with all its reverse-deps)
>
> We would prefer to do (B) since API changes are likely to be minor,
> and new 1.9.z releases are likely not to be too frequent (upstream
> said ~ once a year ; next is due Dec 09 or Jan 10).
>
> Proposed solution:
>
> 1) drop the libruby1.9 package. Replace it with libruby1.9.1.
> ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates
> the Ruby API version (or soname), not the version of Ruby. If Ruby
> 1.9.2 stays API-compatible with 1.9.1, this will not be changed
> (according to the upstream developers).
>
> 2) packages using ruby have to depend on libruby1.9.1. If they also
> require the interpreter, they need to also depend on libruby1.9.1,
> to indicate that they depend on this specific version of the API.
> Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.
>
> 3) ask library maintainers to install to
> /usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,
> to get out of the mix between standard libs and third-party libs.
>
> Migration plans:
> ================
> 1.9.0->1.9.1 migration:
> all packages have to be updated to depend on ruby1.9 and libruby1.9.1,
> and install their files in /usr/lib/ruby/vendor_ruby/1.9.1/
>
> 1.9.1->1.9.2 migration, and later:
> all packages need to be updated to depend on ruby1.9 and libruby1.9.2,
> and install their files in /usr/lib/ruby/vendor_ruby/1.9.2/
>
> Open Questions:
> ===============
> 1) Should we allow for several ruby1.9.n versions in the same suite
> at a given time?
>
> 2) Library packages naming: change from libxxx-ruby1.9 to something
> else? (would be nice to use that opportunity)
> ruby-xxx? (simpler)
> ruby1.9-xxx? stay with libxxx-ruby1.9?
> libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support
> several versions at the same time in the archive)
>
>
> So, comments? :-)
> --
> | Lucas Nussbaum
> | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
> | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
>
>
> --
> To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>
--
Regards,
Luiz Vitor Martinez Cardoso
cel.: (11) 8187-8662
blog: rubz.org
engineer student at maua.br
"Posso nunca chegar a ser o melhor engenheiro do mundo, mas tenha certeza de
que eu vou lutar com todas as minhas forças para ser o melhor engenheiro que
eu puder ser"
