< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事（スレッド移動）
N :次の記事（スレッド移動）
|<:前のスレッド
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事（前）
<:同じ返事先を持つ記事（後）
---:分割してスレッド表示、再表示
| :分割して（縦）スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
Issue #14217 has been updated by shevegen (Robert A. Heiler).
I can't say whether the name that you haved picked for the constant is good or bad - it seems a
bit long. But I agree on the general problem mentioned, so I am all for more fine-tuned control.
The ruby core team may have decide on the name perhaps.
> Currently, we cannot install gems using 2.5.0preview1.
I think there is another bug report that is vaguely related, e. g. a hardcoded ruby version
to 2.5.0 preview1, for ruby 2.4.3, so you may have a point there. Strictly speaking, the
release for 2.4.3 would be invalid if an internal gem depends on ANOTHER ruby version
that is HIGHER than the released ruby. :)
----------------------------------------
Feature #14217: Expose RUBY_PATCHLEVEL_STR or similar with patch level info for rc/preview as a constant
https://bugs.ruby-lang.org/issues/14217#change-68595
* Author: shayonj (Shayon Mukherjee)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
## Problem
When ruby is in release candidate or preview, ```RUBY_PATCHLEVEL``` is ```-1```. Without parsing ```RUBY_DESCRIPTION```, its hard to tell using constant the right and absolute ruby version.
## Proposal
Expose RUBY_PATCHLEVEL_STR as a constant, just like ```RUBY_VERSION``` or ```RUBY_PATCHLEVEL```. So that, we can know the right ruby version, especially when its in preview or release candidate. This is also helpful when using gems that rely on ```RUBY_PATCHLEVEL``` and ```RUBY_VERSION``` to serve the right experience. Example: Bundler, which validates gem installation by making sure right ruby is installed. Currently, we cannot install gems using 2.5.0preview1.
~~~
Your Ruby version is 2.5.0, but your Gemfile specified 2.5.0preview1
~~~
This can be handled in bundler through some different wokraround, but I think by exposing ```RUBY_PATCHLEVEL_STR```, it will be helpful in building the appropriate solutions.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>