[Breaking] Remove defined versions from gem.

[alexaitken]

This PR removes the need for defined_versions.rb and release a new version of the gem with every api version release.

To accomplish this the default coercion used by the gem will accept any version that matches the format YYYY-MM or unstable.

Stricter coercion is still available using ShopifyAPI::VersionCoercers::DefinedOnly this will match the previous behaviour, but the consumer of the gem is now fully responsible for defining the versions they want to allow.

Breaking changes

ShopifyAPI::ApiVersion.defined_known_version has been fully removed since we will no longer maintain the list in the gem.

The new default coercion is generally substitutable, as long as the consumer was not relying on coercion errors to restrict what versions they can call. If that behaviour is important to their application they can use ShopifyAPI::VersionCoercers::DefinedOnly to get that behaviour back.

ShopifyAPI::ApiVersion.latest_stable_version With the list of versions not being part of the gem any more this method will no longer have the data locally to support it.

Deprecations

ShopifyAPI::ApiVersion.define_version(version) define_versions has been moved to the version_coercer and should not be needed globally anymore.
ShopifyAPI::ApiVersion.clear_defined_versions clear_defined_versions has been moved to the version_coercer and should not been needed globally anymore.

This is an alternative the parts #600 that adjusting coercion and removing define_known_versions.

[jtgrenz]

I'm not sure what value this provides developers over the existing implementation. It removes the requirement that the gem be updated with every version release but it forces developers to maintain their own list of versions which I think is problematic when we have an endpoint they can just fetch the current known versions from.

With this implementation developers who want to use the GenerateReleaseCoercer get no validation of the version they choose to use, which maybe fine in production since we can assume everything was tested, but when they use the DefinedOnlyCoercer, they also get no validation of the version they're choosing to define. You can't trust your defined set any more than your undefined set and it is more work to setup. In either case you could use version 2019-01 or 9999-99 and it would be perfectly valid.

I think the removal of the boot definition and the use of a coercion mode you suggested I add to #600 is a better solution.

It still lets developers avoid any upfront checks to start faster their application faster, but it also provides a way to always have the latest up to date information about the current api version set. When they want to test with the defined_only version set, neither 2019-01 or 9999-99 will be valid since the version set is fetched from the api.

[alexaitken]

The intent is to have this replace the coercion switching setup in #600 only.

The rest of #600 would stand.

[jtgrenz]

Ahhh, I'm sorry, I totally misunderstood. I should never review a PR before finishing my first cup of coffee. 🤦‍♂ ☕️

I'm a little conflicted now. On the one hand this keeps everything related to the coercion of a handle into a version away from the actual ApiVersion class and thats arguably a different concern which is good.

But on the other hand, there really isn't a whole lot to the coercion and adding 4 new coercion classes means we have 4 more test suites to maintain. In the default naïve mode, we just return the version matching the handle argument or run ApiVersion.new and cache it. In the stricter mode we raise an error instead of calling ApiVersion.new. While we could argue coercing a handle to the appropriate version is outside the scope of what ApiVersion should do, you could also argue it is still in the scope. It's a bit grey.

I think I'd err on the side of a simpler implementation at the expense of maybe being more OOPy. Keeping all the coercion logic in a single method makes it easier to understand whats actually going on. If we need to add any additional logic to how versions are coerced, then I think moving it out into its own class might be worth the extra overhead.