From: shevegen@... Date: 2019-08-18T10:43:49+00:00 Subject: [ruby-core:94417] [Ruby master Misc#16109] Normalize legacy tag names Issue #16109 has been updated by shevegen (Robert A. Heiler). Sorry for the off-track comment from me - quite an epic task. :) It would be kind of cool if we'd have not only a "time travel" history of all of ruby in general, including the very old ruby releases by matz (like in the 1990s or so) and the versions (including the time/date release); and even trying out old ruby versions, although I am aware that many of these may not compile on modern hardware anymore. I just think this is pretty cool what is done here altogether, from a historic point of view as well (and from a consistency point of view as well). Wikipedia has a shorter summary of the versions at https://en.wikipedia.org/wiki/Ruby_%28programming_language%29#First_publication Obviously git could show more of the old versions. As for the renaming: V1-1-1 -> net_1_1_1 V1-1-3 -> net_1_1_3 testunit_0-1-7 -> testunit_0_1_7 I think it would be better since your suggestion is clearer than the variant before; e. g. the "V" is not necessary, and the rename would be more consistent. I assume there is some practical reason why _ is used rather than '.'. In my own ruby code for dealing with downloading packages from the www, and inferring name and version, I prefer this schemata: NAME_OF_THE_PROGRAM-VERSION HERE so for example: ruby-2.6.3 URL: https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.3.tar.gz python-3.7.4 URL: https://www.python.org/ftp/python/3.7.4/Python-3.7.4.tgz (Oddly enough has the first character upcased) etc... I guess the '.' may not be practical? But I like this schemata the most. Unfortunately there are also numerous oddities or exceptions to this, such as: apt-1.9.2 URL: http://ftp.debian.org/debian/pool/main/a/apt/apt_1.9.2.tar.xz (If this is extracted, it actually becomes apt-1.9.2, so the debian folks don't quite understand why it would be important to have the tarball name be the same as the extracted name.) or boost-1.70.0 URL: https://dl.bintray.com/boostorg/release/1.70.0/source/boost_1_70_0.tar.bz2 Interestingly, boost also uses a similar schemata as the one described in the issue here. There are also programs with numbers as part of their name: polkit-qt-1-0.112.0 URL: http://download.kde.org/stable/apps/KDE4.x/admin/polkit-qt-1-0.112.0.tar.bz2 Took me some time to come to the conclusion here that the first 1 is part of the name of the program. In general, though, the simpler the better, IMO. Sorry for the semi-off-topic comment, I just wanted to give a verbose thumbs up to your current clean-up process here. Consistency is very useful on its own, too. \o/ ---------------------------------------- Misc #16109: Normalize legacy tag names https://bugs.ruby-lang.org/issues/16109#change-80839 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- There are tags with inconsistent names. To browse the history more easily, I propose the following normalization. **Before and after the renames, I'm going to record `git ls-remote` in this ticket. By doing so, we'd be able to revert this ticket's change as needed.** # Ruby's version tags ## v1_3_1_ -> (deleted) This is the same as v1_3_1_990126 except svn-related meta commits. ## RUBY_1_3 -> (deleted) This is the same as v1_3_1_990126 except svn-related meta commits. We also have `ruby_1_3` branch for 1.3 stable branch, and the branch should own that role. ## ruby_1_4_3, ruby1_4_3 -> (deleted) Both tags are the same as `v1_4_3` except svn-related meta commits. ## ruby_1_4_3_pre1 -> v1_4_3_preview1 Just normalize the name. ## ruby_1_8_freeze_candidate -> v1_8_5_freeze_candidate Minor normalization, and clarify the exact version. Thoughts? ## yarv_migration_base -> v1_9_0_yarv_migration_base Make it slightly more consistent with other tags, and clarify the exact version. Thoughts? ## r1_1b9 -> v1_1b9 ## r1_1b9_24 -> v1_1b9_24 ## r1_1b9_25 -> v1_1b9_25 Just make them similar to other tags like v1_1b8, v1_1b9_07. ## v_1_8_5_52 -> (deleted) ## v_1_8_6_30 -> (deleted) ## v_1_8_6_31 -> (deleted) ## v_1_8_6_36 -> (deleted) All of them have their `s/v_/v/` version, and their differences are only a "move to proper name" commit and thus it looks intended to be renamed in that direction. ## v_1_9_1_preview1 -> (deleted) Excluding meta commits, v1_9_1_preview1 is just 1-commit (r19982) ahead of v_1_9_1_preview1. Just leaving v1_9_1_preview1 seems fine. # Library's version tags Currently they're named inconsistently: ``` REXML_2_7_0 RUBY-SHA1_v1_2 SHELL_v0_6 V1-1-1 V1-1-3 forwardable_v1_1 gtk_012 irb_0_9 v0_7_1 v0_7_3 oniguruma_2_2_4 oniguruma_2_2_5 oniguruma_2_2_6 oniguruma_2_2_7 oniguruma_2_2_8 oniguruma_3_4_0 oniguruma_3_5_4 oniguruma_3_6_0 oniguruma_3_7_0 oniguruma_3_7_0_1 testunit_0-1-7 testunit_0-1-8 ``` Especially tags without a library name are very confusing. ## Changes How about having the following changes to this? They are changed to `#{name}_#{x}_#{y}_#{z}` to minimize changes and for consistency with existing tags for now. ``` RUBY-SHA1_v1_2 -> sha1_1_2 V1-1-1 -> net_1_1_1 V1-1-3 -> net_1_1_3 v0_7_1 -> irb_0_7_1 v0_7_3 -> irb_0_7_3 testunit_0-1-7 -> testunit_0_1_7 testunit_0-1-8 -> testunit_0_1_8 ``` ## Unchanged Following things seem to be fine, compared to the above ones. `#{name}_v#{x}_#{y}_#{z}` is allowed in addition to `#{name}_#{x}_#{y}_#{z}`. ``` gtk_012 irb_0_9 REXML_2_7_0 SHELL_v0_6 forwardable_v1_1 oniguruma_2_2_4 oniguruma_2_2_5 oniguruma_2_2_6 oniguruma_2_2_7 oniguruma_2_2_8 oniguruma_3_4_0 oniguruma_3_5_4 oniguruma_3_6_0 oniguruma_3_7_0 oniguruma_3_7_0_1 ``` -- https://bugs.ruby-lang.org/ Unsubscribe: