Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility issues between provider gems #276

Open
sethboyles opened this issue Feb 4, 2022 · 2 comments
Open

Compatibility issues between provider gems #276

sethboyles opened this issue Feb 4, 2022 · 2 comments
Labels

Comments

@sethboyles
Copy link

(This is spun out of a discussion started here)

Some provider gems are not being very actively maintained, and there does not a coordinated effort to ensure inter-compatibility between the various provider gems. As a result it can be very difficult (or impossible) to upgrade to the latest provider versions, because other gems might be locked at older versions of fog-core or other dependencies (see [fog-google#422(https://github.com/fog/fog-google/pull/422)).

Sometimes the providers gems are ostensibly compatible, but result in errors nonetheless (see fog-aliyun#155)

In our efforts to upgrade CloudController to Ruby 3, we have had to make a series of contributions in order make the gems compatible with Ruby 3 and with each other. This in itself is fine, but we would like some assurances that in the future the provider gems won't fall out of line with each other and that we can rely on new versions of the provider gems working with each other.

@geemus
Copy link
Member

geemus commented Feb 4, 2022

Thanks for the context and examples. I'm certainly open to supporting and helping coordinate. That being said, I'm not actively using any of the gems myself any more, so there are some limits to how much access/setup I have for testing and things of that sort.

One thing I think we all agreed on in the originally linked issue is that it would be good to have better visibility into what subset of gems are being actively used (and intermixed) and ideally have some way to know sooner if/when they fall out of compatibility with one another. One possible suggestion was to build a github/action that would test this (perhaps running once a day or something) so that we could know right away if/when things broke and be able to make quicker incremental changes. Hopefully that would avoid us getting back into the place of needing to do a big lift again.

Anyway, I certainly welcome further suggestions and look forward to working together to stabilize and continue to keep these things working in the way we want.

@github-actions
Copy link

github-actions bot commented Apr 6, 2022

This issue has been marked inactive and will be closed if no further activity occurs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants