From Fedora Project Wiki
No edit summary
Line 45: Line 45:
* Rebuilding of all Ruby packages, and all packages depending on Ruby
* Rebuilding of all Ruby packages, and all packages depending on Ruby
* Changes to the search path to comply with the multi-versioning
* Changes to the search path to comply with the multi-versioning
== How To Test ==
<!-- This does not need to be a full-fledged document.  Describe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
A good "how to test" should answer these four questions:
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this feature? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the feature is
working like it's supposed to?
3. What are the expected results of those actions?
-->


=== New Packaging Guidelines ===
=== New Packaging Guidelines ===
Line 78: Line 63:


  repoquery --repoid=rawhide-source --arch=src --whatrequires '*ruby*' | sort | uniq
  repoquery --repoid=rawhide-source --arch=src --whatrequires '*ruby*' | sort | uniq
== How To Test ==
<!-- This does not need to be a full-fledged document.  Describe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
A good "how to test" should answer these four questions:
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this feature? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the feature is
working like it's supposed to?
3. What are the expected results of those actions?
-->


== User Experience ==
== User Experience ==

Revision as of 11:00, 7 January 2013

Ruby 2.0.0

Summary

Ruby 2.0.0 is the latest stable version of Ruby, with major increases in speed and reliability. With this major update from Ruby 1.9.3 in Fedora 18 to Ruby 2.0. in Fedora 19, alongside JRuby, Fedora becomes the superior Ruby development platform.

Owner

  • Email: vondruch@redhat.com

Current status

  • Targeted release: Fedora 19
  • Last updated: 2013-01-07
  • Percentage of completion: 10%


Detailed Description

Ruby 2.0.0 is upstream's new major release of Ruby. It caries new features such as:

  • Refinements
  • Keyword arguments
  • Enumerable#lazy
  • Module#prepend
  • #to_h: Convention for conversion to Hash
  • %i: a literal for symbol array
  • regexp engine was changed to Onigmo
  • DTrace support
  • TracePoint

Yet, it is source level backward compatible with Ruby 1.9.3, so you will continue to work.

The updated Ruby also provides better integration with Fedora, especially JRuby. But not only JRuyb, it is also one step closer to be prepared for other interpreters, such as Rubinius. Providing of custom Ruby loader with working name "multiruby" [1] will allow to easily switch interpreters executing your script, provides fallback to whatever Ruby interpreter is available on you system, yet still keeps backward compatibility with all your Ruby scripts.

[1] https://github.com/bkabrda/multiruby

Benefit to Fedora

Supporting the growth of a Ruby language with a latest release supporting the newest language features, which enables even faster and easier development of Ruby applications. Add to that the multiplatform targetted development we enable downstream parties to do using our distribution.

Scope

The following list includes a summary of changes included in this feature:

  • New Packaging Guidelines for Ruby packages (different virtual provide semantics, native extensions moved into different directory). This has to be done in sync with JRuby related changes to packaging guidelines.
  • Rebuilding of all Ruby packages, and all packages depending on Ruby
  • Changes to the search path to comply with the multi-versioning

New Packaging Guidelines

Drafts of new packaging guidelines will have to be proposed to FPC. You can see the current draft.

Packages that require "ruby(abi) = 1.9.1"

Requires rebuilding numerous packages that depend on ruby(abi) = 1.9.1, or have Requires or BuildRequires for package dependent on ruby(abi) = 1.9.1. All these packages have to be updated to support new virtual provides.

  • 211 in total
repoquery --repoid=rawhide-source --arch=src --whatrequires 'ruby(abi) = 1.9.1' | sort | uniq

Packages that require "*ruby*"

  • 452 in total (211 matches from previous query, of course)
repoquery --repoid=rawhide-source --arch=src --whatrequires '*ruby*' | sort | uniq

How To Test

User Experience

Dependencies

Contingency Plan

Documentation

Release Notes

  • The Ruby 2.0.0 breaks ABI compatibility with previous version of Ruby, therefore soname was bumped. All RubyGems which use binary extensions should be rebuilt. All applications which use Ruby binding should be rebuilt. Nevertheless, since upstream payed great attention to source compatibility, no changes to your code are needed.
  • RubyGems with binary extensions now use different directory structure, to provide better compatibility with JRuby and other interpreters. All libraries need to be adjusted to this change. This change is reflected in new packaging guidelines draft.

Comments and Discussion