As most people in Japan should know by now, a new era of the Japanese calendar will start in May 2019.
It is not clear when the new era name will be announced, but it may be at rather short notice.
The Unicode consortium has made up a plan about how to deal with this, see http://blog.unicode.org/2018/09/new-japanese-era.html. Among else, they will encode an equivalent of the current ㍽, ㍼, ㍻, and plan to publish a special version of the Unicode standard numbered 12.1.
We should start to discuss and tentatively decide what (if anything) will be needed for Ruby. Alternatives include the following two and others inbetween.
Follow past years where the update to a new Unicode version is done with the Ruby version release around Christmas. That would mean we upgrade to Unicode 12 around Christmas 2019. At that time, we can include the changes in 12.1 without any problems.
Implement the upgrade to Unicode 12 as quickly as possible in trunk, implement Unicode 12.1 as soon as available in trunk, and backport the changes needed for the new era name to older Ruby versions.
There has been an announcement recently in the Japanese news that the Japanese government will make sure the new era name is being published at least one month before the era change. The era change is planned for May 1st, 2019. This means that the new era name should be know on April 1st, 2019 at the latest.
I have verified that with the beta files for Unicode Version 12.1.0 at https://www.unicode.org/Public/12.1.0/ucd/, Ruby compiles and runs all tests (make check) successfully.
Please note that different from other betas, this beta uses dummy data: The dummy for the new Japanese era name is 左右 (left right):
32FF;SQUARE ERA NAME SAYUU;So;0;L;<square> 5DE6 53F3;;;;N;;;;;
A beta release for Unicode 12.1.0 should be available by tomorrow. The official release of Unicode 12.1.0 is planned for May 7.
This raises the question of whether we should release a Ruby version before May 1st (with the beta data) or after May 7th. For the former, we would have to cheat a bit by introducing some logic into the build process that can pretend that a beta version is already final.
This raises the question of whether we should release a Ruby version before May 1st (with the beta data) or after May 7th. For the former, we would have to cheat a bit by introducing some logic into the build process that can pretend that a beta version is already final.
My preference, also for issue #15742, would be to move ahead, so that Ruby users who need the new functionality can get it.
Updated by 
Updated by