remove references to deprecated ::Parts and ::UploadIO

[jsvd]

Here's my attempt at bringing faraday-multipart up to par with multipart-post recent class reorganization changes.
This PR:

• changes class references according to Rework file structure & license header. socketry/multipart-post#89
  • ::UploadIO to ::Multipart::Post::UploadIO
  • ::Parts to ::Multipart::Post::Parts
• replaces fine grained requires with require 'multipart/post' as per recommendation
• bumps this gem to the next major version as it now has a lower bound requirement of 'multipart-post', '>= 2.2.0' (where previously it was >= 1.2. This change can be made to a minor or patch version bump instead, up to the maintainer.

fixes #5

[olleolleolle]

Thanks for the PR!

I'd like to see if we were able to get this working with both the versions before the change in structure and after. Would it be a lot of changes to this PR?

[olleolleolle]

(And, as a follow-up, don't include changes to the gem version in this PR, it's a later decision what version number to use. We change that during the release process.)

[jsvd]

I'd like to see if we were able to get this working with both the versions before the change in structure and after. Would it be a lot of changes to this PR?

Not a lot, do you prefer to achieve bwc through detecting the multipart-post gem version (from version.rb) or through defined? ?

(And, as a follow-up, don't include changes to the gem version in this PR, it's a later decision what version number to use. We change that during the release process.)

Will do.

[olleolleolle]

@jsvd In this case, I'd prefer the very explicit version comparison! Thanks for asking.

[mashhurs]

LGTM!

[jsvd]

@olleolleolle let me know what you think. Because multipart-post 2.1 has a different file structure than 2.2, even checking the gem's VERSION can cause deprecation warnings. This is why I resorted to doing require + begin/rescue.

[olleolleolle]

@jsvd Thanks for keeping at it! This is a tricky thing.

[olleolleolle]

Steps forward!

[ioquatix]

Thanks for your patient, thoughtful and thorough work.

[olleolleolle]

This looks 👍 and I thank you, @jsvd!

[olleolleolle]

This has now been released as https://rubygems.org/gems/faraday-multipart/versions/1.0.4

[myronmarston]

Did you mean to declare a dependency on any future version of multipart-post? Presumably 3.0, 4.0, 17.0, etc will likely have breaking changes, but this version constraint is essentially >= 2.0. If you want to to depend on any 2.x version this should probably be ~> 2.0.

[ioquatix]

I'd advise to use ~> 2.0.

[olleolleolle]

Thanks! a3609a6 now uses that.

(👋 Hi, everyone!)

[jsvd]

This change is unnecessary as ~> 2 is equivalent to ~> 2.0:

irb(main):001:0> Gem::Requirement.new('~> 2').satisfied_by? Gem::Version.new("2.0")
=> true
irb(main):002:0> Gem::Requirement.new('~> 2').satisfied_by? Gem::Version.new("2.2")
=> true
irb(main):003:0> Gem::Requirement.new('~> 2').satisfied_by? Gem::Version.new("1")
=> false
irb(main):004:0> Gem::Requirement.new('~> 2').satisfied_by? Gem::Version.new("3.0")
=> false
irb(main):005:0> Gem::Requirement.new('~> 2').satisfied_by? Gem::Version.new("4.0")
=> false

From Rubygem docs https://guides.rubygems.org/patterns/:

It’s also important to know that if you specify a major version only, like this:

spec.add_runtime_dependency 'library', '~> 2'

It will only use the latest version from the 2.x series – so 2.3.0 – and not 3.0.0. This behaviour may surprise some people, but automatically allowing any major version past version 2 is more surprising behaviour.

[olleolleolle]

Thanks, @jsvd, for details!

(The change in the gemspec is now "the less surprising one".)

[myronmarston]

@jsvd thanks for teaching me something new! I didn't realize rubygems had a special case for a single digit...

[ioquatix]

I didn't know it either! Thanks.

[iMacTia]

TIL! Thank you @jsvd 🙏