Proper Semantic Versioning

@kou

@kou @nobu, the two most recent releases 3.2.7 and 3.2.8 should be major versions as they introduce strscan which seems to require some native extensions and compilation on systems. This is breaking my world with folks using Chef. Can you please yank those and make this 4.x.x or something?

For Chef folks looking for a fix, add the following to your cookbooks metadata.rb:

# Temporary Workaround (https://github.com/ruby/rexml/issues/131)
gem 'rexml', '= 3.2.6'

You can also install gcc in your kitchen using:

lifecycle:
  post_create:
    # Temporary Workaround (https://github.com/ruby/rexml/issues/131)
    - remote: sudo yum install -y gcc

Thanks

This should be prioritized as impacting many.

Note that the old version of 3.2.6 is subject to a DoS CVE: https://www.ruby-lang.org/en/news/2024/05/16/dos-rexml-cve-2024-35176/.

Impact of the vulnerability may be limited, but this may be a reason to favour the "install gcc" approach over pinning the old version.

+1, or at least 3.3.0 would be acceptable? Would also be nice to see the gcc dependency listed in the Readme for this project as well.

In my case, the requiring Gem is ruby-dbus which has the following: s.add_runtime_dependency "rexml". Since no version information is listed there, it doesn't actually matter what version was introduced here - it would still have broken for me. My guess is that most Chef users having problems are using the systemd cookbook.

I will recommend that ruby-dbus changes their dependency to here to have a version, such as ~> 3.2 for their current version and then they bump their version for a dependency update to the new version here as well.

For the sake of those who think they have the same problem (and the web crawlers), here is dependency chain I have that got me here:

An error occurred while installing strscan (3.1.0), and Bundler cannot continue.

       In Gemfile:
         dbus-systemd was resolved to 1.1.2, which depends on
           ruby-dbus was resolved to 0.23.1, which depends on
             rexml was resolved to 3.2.8, which depends on
        strscan

Can you please yank those and make this 4.x.x or something?

It's impossible. If we yanked them, it breaks the many of Ruby application.

Can you please yank those and make this 4.x.x or something?

It's impossible. If we yanked them, it breaks the many of Ruby application.

It breaks no one. You released two versions this morning which broke many. I highly doubt anyone pinned the versions to this yet. This is 💯 a major breaking change.

Major minor patch. This is far from a patch or a minor change.

Secondary variant with (very old ruby, bundler, probably solvable but surprising):

App 77401 output: Error: The application encountered the following error: You have already activated strscan 1.0.0, but your Gemfile requires strscan 3.1.0. Since strscan is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports strscan as a default gem. (Gem::LoadError)
App 77401 output:     /home/clintel/.rbenv/versions/2.6.10/lib/ruby/2.6.0/bundler/runtime.rb:319:in `check_for_activated_spec!'
App 77401 output:     /home/clintel/.rbenv/versions/2.6.10/lib/ruby/2.6.0/bundler/runtime.rb:31:in `block in setup'
App 77401 output:     /home/clintel/.rbenv/versions/2.6.10/lib/ruby/2.6.0/forwardable.rb:230:in `each'
App 77401 output:     /home/clintel/.rbenv/versions/2.6.10/lib/ruby/2.6.0/forwardable.rb:230:in `each'
App 77401 output:     /home/clintel/.rbenv/versions/2.6.10/lib/ruby/2.6.0/bundler/runtime.rb:26:in `map'
App 77401 output:     /home/clintel/.rbenv/versions/2.6.10/lib/ruby/2.6.0/bundler/runtime.rb:26:in `setup'

Could you explain why Chef is related to REXML? #131 (comment) ?

Could you also explain what is "kitchen" in Chef context?

@kou

@kou the "kitchen" is a test environment for using Chef. It's not really relevant to the problem at hand but it's useful for those with chef/kitchen related problems to see how to install gcc. The solution above is specific to environments using yum but it's enough to get someone going the right direction.

Why Chef is related to REXML: see my dependency chain above - where it starts is the systemd cookbook is widely used, and that uses the dbus-systemd gem.

While I agree the versioning here was bad, this could be fixed this up the dependency chain - for example the version could be locked here: mvidner/ruby-dbus#143, but I'd have to keep looking up the chain for the same problems I guess.

Thanks. If this is related to ruby-dbus (via the systemd cookbook) as you explained, the semantic versioning isn't related to this. Because ~> ... isn't used in ruby-dbus: https://github.com/mvidner/ruby-dbus/blob/5f98ee3cf506ff0bd53b72ce952b1b89881ab64a/ruby-dbus.gemspec#L28

If you don't want to use REXML 3.2.7 or later, you must pin REXML 3.2.6 by yourself. (I'm not sure whether Chef uses Gemfile for dependency management or not.)
In general, I don't recommend it because 3.2.6 or earlier has a security vulnerability: GHSA-vg3r-rm7w-2xgh
If you pin REXML, use it at your own risk.

(We don't need to change ruby-dbus because there isn't any reason that ruby-dbus needs to pin REXML. ruby-dbus can work with any versions of REXML.)

Asciidoctor/Antora user here. 3.2.7/3.2.8 broke our CI as well. Adding dependencies (especially native) in patch-release was not a good idea.

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
    current directory: /usr/lib/ruby/gems/3.2.0/gems/strscan-3.1.0/ext/strscan
/usr/bin/ruby extconf.rb
mkmf.rb can't find header files for ruby at /usr/lib/ruby/include/ruby.h
You might have to install separate package for the ruby development
environment, ruby-dev or ruby-devel for example.
extconf failed, exit code 1
Gem files will remain installed in /usr/lib/ruby/gems/3.2.0/gems/strscan-3.1.0
for inspection.
Results logged to
/usr/lib/ruby/gems/3.2.0/extensions/x86_64-linux-musl/3.2.0/strscan-3.1.0/gem_make.out
  /usr/lib/ruby/3.2.0/rubygems/ext/builder.rb:119:in `run'
  /usr/lib/ruby/3.2.0/rubygems/ext/ext_conf_builder.rb:28:in `build'
  /usr/lib/ruby/3.2.0/rubygems/ext/builder.rb:187:in `build_extension'
  /usr/lib/ruby/3.2.0/rubygems/ext/builder.rb:221:in `block in build_extensions'
  /usr/lib/ruby/3.2.0/rubygems/ext/builder.rb:218:in `each'
  /usr/lib/ruby/3.2.0/rubygems/ext/builder.rb:218:in `build_extensions'
  /usr/lib/ruby/3.2.0/rubygems/installer.rb:846:in `build_extensions'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/rubygems_gem_installer.rb:72:in
`build_extensions'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/rubygems_gem_installer.rb:28:in
`install'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/source/rubygems.rb:201:in
`install'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/installer/gem_installer.rb:54:in
`install'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/installer/gem_installer.rb:16:in
`install_from_spec'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/installer/parallel_installer.rb:156:in
`do_install'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/installer/parallel_installer.rb:147:in
`block in worker_pool'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/worker.rb:62:in
`apply_func'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/worker.rb:57:in
`block in process_queue'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/worker.rb:54:in
`loop'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/worker.rb:54:in
`process_queue'
/usr/lib/ruby/gems/3.2.0/gems/bundler-2.4.15/lib/bundler/worker.rb:90:in
`block (2 levels) in create_threads'
An error occurred while installing strscan (3.1.0), and Bundler cannot continue.
In Gemfile:
  asciidoctor-pdf was resolved to 2.3.15, which depends on
    prawn-svg was resolved to 0.34.2, which depends on
      rexml was resolved to 3.2.8, which depends on
        strscan

You might have to install separate package for the ruby development
environment, ruby-dev or ruby-devel for example.

This part in the message will fix your CI.

This part in the message will fix your CI.

I believe my CI should not have broke in the first place by a patch update of rexml. There's nothing wrong with adding/removing dependencies, but not this way by breaking everyone. I would not say a single word if 3.2.7/3.2.8 was instead called 4.x.x.

Could you share your repository for the CI log?

Thumbs downing people with evidence is very immature. I was able to fix my organization but it took "a village" and a monumental effort from my team to come to a resolution.

This is a Ruby core library, consumed by a wide spread of tooling. A simple acknowledgement would be the adult thing to do here.
I agree that upstream needs a better pinning strategy, but this should have been a minor or major.

pin rexml as a result of ruby/rexml#131

This also broke iOS builds using the yukiarrr/ios-build-action GitHub action, which uses Fastlane:

[19:06:53]: Error setting value 'dev-client/ios/TerrasoLandPKS.xcworkspace' for option 'workspace'
[19:06:53]: You passed invalid parameters to 'build_app'.
[19:06:53]: Check out the error below and available options by running `fastlane action build_app`

full log.

Why do we need to use REXML with Chef on Windows?

Chef cookbooks does not need to be OS-dependant and could include different recipes and cookbook references for different environment including different operating systems. However, the OS detection is execution-time, not compile-time and as such the gem dependency is built for all the dependant cookbook available.

(Last statement is my understanding, could be wrong. I'm the user of chef, not the developer)

I know almost nothing about chef, but surely you should be installing from a Gemfile.lock to freeze the exact versions of dependencies you want. Then you can run bundle update to update the Gemfile.lock in a less anxiety producing environment than production to discover these things…

installing unconstrained software from the internet straight onto your servers seems like a bad idea

In my opinion

In general, we should not customize well-defined definitions without changing their definition names. It makes communication difficult because each of us may think other thing with the same definition name. If the well-defined definition isn't matched for us, we should not use the original defined name.

In this case, if we want to use dependency change for versioning schema, we should not refer the semantic versioning. Because the semantic versioning definition says that dependency change isn't related to major/minor/patch release explicitly.

In the future, when planning for a new release, if there are dependency changes (particularly if those changed dependencies will require building native extensions), it would be good to communicate with some of the direct users before such changes occur.

It seems that it's not realistic. You can see all direct users by https://rubygems.org/gems/rexml/reverse_dependencies . We can't choose who should be communicated.

Can REXML users who want to improve REXML and REXML users test unreleased version in their CI (or something) instead?
If they use Gemfile, you can use gem "rexml", git: "https://github.com/ruby/rexml.git" for it.
See also: https://bundler.io/v2.5/man/gemfile.5.html

@paulschreiber

@paulschreiber Could you open a new issue for it? It may be a regression bug. Could you also provide an XML file that is related to it and related codes that use REXML in the new issue?

Chef cookbooks does not need to be OS-dependant and could include different recipes and cookbook references for different environment including different operating systems. However, the OS detection is execution-time, not compile-time and as such the gem dependency is built for all the dependant cookbook available.

I'm not familiar with Chef but, in general, needless dependencies should not be included for production.
If Chef users think so too, could you feedback it to Chef?

(CAT-1643) Exclude rexml versions due to issues on Windows

(CAT-1871) Pin rexml due to issues on Windows

(CAT-1871) Pin `rexml` due to issues on Windows

Just in case it encourages someone else to upgrade .. I had no trouble compiling strscan on Debian 11 "bullseye".

FROM ruby:3.0.6-bullseye
...
Fetching strscan 3.1.0
Installing strscan 3.1.0 with native extensions

REXML 3.2.9 doesn't require strscan 3.0.9 or later. It can use strscan installed as a default gem.
So this problem will be disappeared.

Semantic versioning is unrelated. I close this.

I'm getting this error on 3.2.9:

REXML::ParseException - #<TypeError: wrong argument type String (expected Regexp)>
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/source.rb:220:in `scan'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/source.rb:220:in `match'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/parsers/baseparser.rb:227:in `pull_event'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/parsers/baseparser.rb:207:in `pull'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/parsers/treeparser.rb:23:in `parse'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/document.rb:448:in `build'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/document.rb:101:in `initialize'
/Library/Ruby/Gems/2.6.0/gems/xcodeproj-1.24.0/lib/xcodeproj/workspace.rb:83:in `new'
/Library/Ruby/Gems/2.6.0/gems/xcodeproj-1.24.0/lib/xcodeproj/workspace.rb:83:in `from_s'
/Library/Ruby/Gems/2.6.0/gems/xcodeproj-1.24.0/lib/xcodeproj/workspace.rb:66:in `new_from_xcworkspace'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer/user_project_integrator.rb:102:in `create_workspace'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer/user_project_integrator.rb:71:in `integrate!'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:929:in `block in integrate_user_project'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:64:in `section'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:925:in `integrate_user_project'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:185:in `integrate'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:170:in `install!'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/command/install.rb:52:in `run'
/Library/Ruby/Gems/2.6.0/gems/claide-1.0.3/lib/claide/command.rb:334:in `run'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/command.rb:52:in `run'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/bin/pod:55:in `<top (required)>'
/usr/local/bin/pod:23:in `load'
/usr/local/bin/pod:23:in `<main>'
...
wrong argument type String (expected Regexp)
Line: 1
Position: 38
Last 80 unconsumed characters:
<?xml version="1.0" encoding="UTF-8"?>
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/parsers/treeparser.rb:96:in `rescue in parse'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/parsers/treeparser.rb:21:in `parse'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/document.rb:448:in `build'
/Library/Ruby/Gems/2.6.0/gems/rexml-3.2.9/lib/rexml/document.rb:101:in `initialize'
/Library/Ruby/Gems/2.6.0/gems/xcodeproj-1.24.0/lib/xcodeproj/workspace.rb:83:in `new'
/Library/Ruby/Gems/2.6.0/gems/xcodeproj-1.24.0/lib/xcodeproj/workspace.rb:83:in `from_s'
/Library/Ruby/Gems/2.6.0/gems/xcodeproj-1.24.0/lib/xcodeproj/workspace.rb:66:in `new_from_xcworkspace'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer/user_project_integrator.rb:102:in `create_workspace'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer/user_project_integrator.rb:71:in `integrate!'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:929:in `block in integrate_user_project'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:64:in `section'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:925:in `integrate_user_project'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:185:in `integrate'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:170:in `install!'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/command/install.rb:52:in `run'
/Library/Ruby/Gems/2.6.0/gems/claide-1.0.3/lib/claide/command.rb:334:in `run'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/lib/cocoapods/command.rb:52:in `run'
/Library/Ruby/Gems/2.6.0/gems/cocoapods-1.15.2/bin/pod:55:in `<top (required)>'
/usr/local/bin/pod:23:in `load'
/usr/local/bin/pod:23:in `<main>'

The error goes away when using 3.2.6.

@fertrig

@fertrig Thanks for your report. Could you open a new issue for it? It's not related to this issue.

Navigation Menu

Repository navigation

Proper Semantic Versioning #131

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Proper Semantic Versioning #131

Description

Activity

spacefuntus commented on May 16, 2024

igorwwwwwwwwwwwwwwwwwwww commented on May 16, 2024

elbartostrikesagain commented on May 16, 2024

hsbt commented on May 16, 2024

bdwyertech commented on May 16, 2024

doconnor-clintel commented on May 17, 2024

kou commented on May 17, 2024

elbartostrikesagain commented on May 17, 2024

kou commented on May 17, 2024

slonopotamus commented on May 17, 2024

kou commented on May 17, 2024

slonopotamus commented on May 17, 2024

kou commented on May 17, 2024

bdwyertech commented on May 17, 2024

21 remaining items

paulschreiber commented on May 21, 2024

ariksu commented on May 21, 2024

KJTsanaktsidis commented on May 21, 2024

kou commented on May 21, 2024

kou commented on May 21, 2024

kou commented on May 21, 2024

jaredbeck commented on Jun 5, 2024

kou commented on Jun 9, 2024

fertrig commented on Jun 10, 2024

kou commented on Jun 10, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions