[#90399] [Ruby trunk Feature#14813] [PATCH] gc.c: make gc_enter+gc_exit pairs dtrace probes, too — ko1@...
Issue #14813 has been updated by ko1 (Koichi Sasada).
3 messages
2018/12/10
[#90417] [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD — naruse@...
Issue #15398 has been reported by naruse (Yui NARUSE).
4 messages
2018/12/11
[#90423] Re: [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD
— Eric Wong <normalperson@...>
2018/12/11
[email protected] wrote:
[#90519] Spoofing warnings for mail from bugs.ruby-lang.org — Charles Oliver Nutter <headius@...>
I'm getting a spoofing warning for emails sent from bugs.ruby-lang.org when
4 messages
2018/12/13
[#90522] Re: Spoofing warnings for mail from bugs.ruby-lang.org
— Eric Wong <normalperson@...>
2018/12/13
Charles Oliver Nutter <[email protected]> wrote:
[#90533] [Ruby trunk Feature#15413] unmarkable C stack (3rd stack) — normalperson@...
Issue #15413 has been reported by normalperson (Eric Wong).
3 messages
2018/12/14
[#90581] [Ruby trunk Bug#15424] Ruby 2.6.0rc1 & 2.6.0rc2 mutex exception — mat999@...
Issue #15424 has been reported by splitice (Mathew Heard).
3 messages
2018/12/17
[#90595] [Ruby trunk Bug#15430] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been reported by hsbt (Hiroshi SHIBATA).
3 messages
2018/12/18
[#90614] [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been updated by hsbt (Hiroshi SHIBATA).
4 messages
2018/12/19
[#90630] Re: [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI
— Eric Wong <normalperson@...>
2018/12/20
> It still exists. https://rubyci.org/logs/rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181218T230003Z.fail.html.gz
[#90820] Re: [ruby-cvs:73697] k0kubun:r66593 (trunk): accept_nonblock_spec.rb: skip spurious failure — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/12/30
[ruby-core:90738] [Ruby trunk Feature#15456] Adopt some kind of consistent versioning mechanism
From:
samuel@...
Date:
2018-12-27 00:17:03 UTC
List:
ruby-core #90738
Issue #15456 has been updated by ioquatix (Samuel Williams). > But dropping old rubies will happen every year and it can affect gems to remove legacy code. If it is considered as breaking changes as you said, it will cause major bump and it's false positive for normal users who runs application with current rubies. I'm sorry, but I don't understand how this is a problem. Can you explain it in more detail with an example? ---------------------------------------- Feature #15456: Adopt some kind of consistent versioning mechanism https://bugs.ruby-lang.org/issues/15456#change-75916 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- After the discussion https://github.com/ruby/bigdecimal/issues/114 I feel like we would benefit from some consistent versioning mechanism across all of Ruby. So far, I feel the majority of Ruby uses some form of semantic versioning. For the sanity of all Ruby users, I think it would be a good policy to adopt this across core Ruby and standard gems. There are some previous discussions around this: - https://bugs.ruby-lang.org/issues/9215 - https://bugs.ruby-lang.org/projects/ruby/wiki/GeneralMaintenancePolicy - https://bugs.ruby-lang.org/issues/8835 So, the questions are as follows: - Can we adopt Semantic Versioning (or as much of it as possible) across Ruby? - Would such a change help users of Ruby? - Is there existing documentation about how version number works? - How does it deviate from Semantic Versioning? - Is this deviation important and worth the additional complexity for our users? As an aside: - How do other implementations advertise compatibility with Ruby? - JRuby and RBX have totally different version numbers that are difficult to understand w.r.t. compatibility with mainline CRuby. My main concern is how difficult this is for everyone to keep track of and also the implied assumptions (e.g. breaking change if and only if major versions bump). If different parts of Ruby use different versioning scheme, it is hard for our users to define dependencies which don't cause broken software. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>