From Fedora Project Wiki
mNo edit summary
No edit summary
 
(7 intermediate revisions by 2 users not shown)
Line 56: Line 56:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1660176 #1660176]
* Release Notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/267 #267]


== Detailed Description ==
== Detailed Description ==
Line 118: Line 119:
** Rebuild of packages with binary extensions (i.e. packages which depends on libruby) will be handled automatically, but some packages might need fixes/updates to support Ruby 2.6 properly.  
** Rebuild of packages with binary extensions (i.e. packages which depends on libruby) will be handled automatically, but some packages might need fixes/updates to support Ruby 2.6 properly.  


* Release engineering: [https://pagure.io/releng/issue/7936 #7936] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/7936 #7936] <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
Line 186: Line 187:
* Contingency mechanism: We would like to get a special buildroot tag to be able to rebuild necessary the packages with Ruby 2.6. If anything goes wrong, the tag could be easily dropped and previous version of Ruby 2.5 and its dependencies stays intact. The tag would be merged into F30 after everything is rebuild.<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: We would like to get a special buildroot tag to be able to rebuild necessary the packages with Ruby 2.6. If anything goes wrong, the tag could be easily dropped and previous version of Ruby 2.5 and its dependencies stays intact. The tag would be merged into F30 after everything is rebuild.<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: Mass Rebuild (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Mass Rebuild  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 196: Line 197:
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* [http://www.ruby-doc.org/ Help and documentation for the Ruby programming language]
* [http://www.ruby-doc.org/ Help and documentation for the Ruby programming language]
* [https://github.com/ruby/ruby/blob/v2_6_0_preview3/NEWS Ruby 2.6.0.preview3NEWS]
* [https://github.com/ruby/ruby/blob/v2_6_0_preview3/NEWS Ruby 2.6.0.preview3 NEWS]


== Release Notes ==
== Release Notes ==
Line 209: Line 210:
https://github.com/ruby/ruby/blob/trunk/NEWS
https://github.com/ruby/ruby/blob/trunk/NEWS


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF30]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 17:32, 17 December 2018


Ruby 2.6

Summary

Ruby 2.6 is the latest stable version of Ruby. Many new features and improvements are included for the increasingly diverse and expanding demands for Ruby. With this major update from Ruby 2.5 in Fedora 29 to Ruby 2.6 in Fedora 30, Fedora becomes the superior Ruby development platform.

Owner

Current status

Detailed Description

Ruby 2.6 is upstream's new major release of Ruby. Many new features and improvements are included.

JIT

Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler.

JIT compiler aims to improve performance of any Ruby program execution. Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native code.

The main purpose of this JIT release is to provide a chance to check if it works for your platform and to find out security risks before the 2.6 release. JIT compiler is supported when Ruby is built by GCC, Clang, or Microsoft VC++, which needs to be available on runtime. Otherwise you can’t use it for now.

As of Ruby 2.6.0 preview3, we achieved 1.7x faster performance than Ruby 2.5 on CPU-intensive non-trivial benchmark workload called Optcarrot. The performance on memory-intensive workload like Rails application are going to be improved as well.

RubyVM::AST [Experimental]

Ruby 2.6 introduces RubyVM::AST module.

This module has parse method which parses a given ruby code of string and returns AST (Abstract Syntax Tree) nodes, and parse_file method which parses a given ruby code file and returns AST nodes. RubyVM::AST::Node class is also introduced. You can get location information and children nodes from Node objects. This feature is experimental. Compatibility of the structure of AST nodes are not guaranteed.

New Features

  • Add a new alias then to Kernel#yield_self.
  • Add Random.bytes.
  • Add Binding#source_location. This method returns the source location of binding, a 2-element array of __FILE__ and __LINE__.
  • Add :exception option to let Kernel.#system raise error instead of returning false.
  • Add a new alias then to Kernel#yield_self.
  • else without rescue now causes a syntax error. [EXPERIMENTAL]
  • Constant names may start with a non-ASCII capital letter.
  • An endless range, (1..), is introduced. It works as it has no end.

Performance improvements

  • Speedup Proc#call because we don’t need to care about $SAFE any more. With lc_fizzbuzz benchmark it makes x1.4 speed improvement.
  • Speedup block.call where block is passed block parameter. Ruby 2.6 improves the performance of passed block calling. There can observed 2.6x improvement with micro-benchmarks.
  • Transient Heap (theap) is introduced. theap is managed heap for short-living memory objects which are pointed by specific classes. For example, making small and short-living Hash object is x2 faster. With rdoc benchmark, 6-7% performance improvement is observed.

Other notable changes since 2.5

  • $SAFE is a process global state and we can set 0 again.
  • Passing safe_level to ERB.new is deprecated. trim_mode and eoutvar arguments are changed to keyword arguments.
  • Merged RubyGems 3.0.0.beta2.
  • Merge Bundler as default gem.

Benefit to Fedora

With a latest release, Ruby language is supporting the newest language features, which enables even faster and easier development of Ruby applications.

Scope

.

  • Other developers:
    • Rebuild of packages with binary extensions (i.e. packages which depends on libruby) will be handled automatically, but some packages might need fixes/updates to support Ruby 2.6 properly.
  • Release engineering: #7936
    • Separate Koji tag for package rebuild will be needed.
    • List of deliverables: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

  • User specific Ruby binary extensions need to be rebuild.

How To Test

  • No special hardware is needed.
  • To test, install Ruby 2.6. The test builds are pusblished in PR or on Ruby-SIG ML
  • Try to locally rebuild your packages using Ruby 2.6.
  • Use the packages with your applications previously written in Ruby.
  • If something doesn't work as it should, let us know.

User Experience

The Ruby programs/scripts should behave as they were used to.

Dependencies

$ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq | wc -l
156

Contingency Plan

  • Contingency mechanism: We would like to get a special buildroot tag to be able to rebuild necessary the packages with Ruby 2.6. If anything goes wrong, the tag could be easily dropped and previous version of Ruby 2.5 and its dependencies stays intact. The tag would be merged into F30 after everything is rebuild.
  • Contingency deadline: Mass Rebuild
  • Blocks release? No
  • Blocks product? No

Documentation

Release Notes

  • The Ruby 2.6 bumps soname, therefore Ruby packages, which use binary extensions, should be rebuilt. Nevertheless, since upstream paid great attention to source compatibility, no changes to your code are needed.

https://github.com/ruby/ruby/blob/trunk/NEWS