Expose RUBY_PATCHLEVEL_STR or similar with patch level info for rc/preview as a constant
When ruby is in release candidate or preview,
-1. Without parsing
RUBY_DESCRIPTION, its hard to tell using constant the right and absolute ruby version.
Expose RUBY_PATCHLEVEL_STR as a constant, just like
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_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.
#3 [ruby-core:84403] Updated by shevegen (Robert A. Heiler) 4 months ago
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. :)
#4 [ruby-core:84407] Updated by shayonj (Shayon Mukherjee) 4 months ago
Agreed that it may appear as long. I chose this as a proposal, because it was already defined and was simpler to expose. Example:
From 8cef26bbdf314dccf1d36984a49c35f0a815bbea Mon Sep 17 00:00:00 2001 From: Shayon Mukherjee <firstname.lastname@example.org> Date: Thu, 21 Dec 2017 16:51:13 -0800 Subject: [PATCH] Introduce RUBY_PATCHLEVEL_STR constant --- version.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/version.c b/version.c index 4c7b1abb40..6c66c12eb0 100644 --- a/version.c +++ b/version.c @@ -30,6 +30,7 @@ const char ruby_version = RUBY_VERSION; const char ruby_release_date = RUBY_RELEASE_DATE; const char ruby_platform = RUBY_PLATFORM; const int ruby_patchlevel = RUBY_PATCHLEVEL; +const char ruby_patchlevel_str = RUBY_PATCHLEVEL_STR; const char ruby_description = RUBY_DESCRIPTION; const char ruby_copyright = RUBY_COPYRIGHT; const char ruby_engine = "ruby"; @@ -59,6 +60,12 @@ Init_version(void) * the patchlevel will be -1 */ rb_define_global_const("RUBY_PATCHLEVEL", MKINT(patchlevel)); + /* + * The patchlevel string for this ruby. If this is a development build + * of ruby the patchlevel string will be dev otherwise the respective + * rc or preview candidate. + */ + rb_define_global_const("RUBY_PATCHLEVEL_STR", MKSTR(patchlevel_str)); /* * The SVN revision for this ruby. */ -- 2.15.1
RUBY_PATCHLEVEL_STR still makes sense since it differentiates it from
RUBY_PATCHLEVEL, but at the same time I am not too big on the idea of having the the type of the return value in a constant name. I am more than happy to go with a different name. Few others I had in mind were