From: takashikkbn@... Date: 2019-08-18T11:10:43+00:00 Subject: [ruby-core:94418] [Ruby master Misc#16109] Normalize legacy tag names Issue #16109 has been updated by k0kubun (Takashi Kokubun). Yeah, I personally like vX.Y.Z rather than vX_Y_Z too, especially because it's closer to what `rake release` does by default. However, newer tags are also tagged as vX_Y_Z, and renaming the new tags would be disruptive unlike renaming legacy tags for EOL Rubies and libraries. Thus this ticket intentionally avoids renaming newer tags, and the renamed ones are just made consistent with the newer ones. Making them consistent first would be beneficial anyway even if we wanted to change the naming convention eventually. ---------------------------------------- Misc #16109: Normalize legacy tag names https://bugs.ruby-lang.org/issues/16109#change-80840 * 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: