Issue #14217 has been updated by shayonj (Shayon Mukherjee).


Agreed that it may appear as long. I chose this as a proposal, because it was already defined and was simpler to expose. Example:  

~~~ diff
From 8cef26bbdf314dccf1d36984a49c35f0a815bbea Mon Sep 17 00:00:00 2001
From: Shayon Mukherjee <dev / shayon.me>
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


~~~

IMO, ```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 ```RUBY_PATCHNAME``` and ```RUBY_PATCHLEVEL_NAME```.


----------------------------------------
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-68600

* 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>