Update Dependencies

[plribeiro3000]

As @mdarby mentioned here this gem is relying on a really old version of fog-core and i would like to ask to remove the pessimistic dependency if possible. That might give us a lot of headaches and conflicts with other providers if they specify different versions.

So this:

spec.add_dependency 'fog-core',  '~> 1.27'
spec.add_dependency 'fog-json',  '~> 1.0'
spec.add_dependency 'fog-xml',   '~> 0.1'

would become something like this:

spec.add_dependency 'fog-core',  '>= 1.27'
spec.add_dependency 'fog-json',  '>= 1.0'
spec.add_dependency 'fog-xml',   '>= 0.1'

[geemus]

Sounds reasonable. @fog/fog-aws any concerns?

[lanej]

would ~> be more appropriate? Semvar for the fog dependencies ?

[plribeiro3000]

@lanej The main problem imo is that you are still locking it (event that on a minor version) and since we have (will) many providers i can see conflicts happening really easy because of that.
Ideally all providers should just list dependencies but not enforce a version but sometimes we might need so just need to be extra careful here.

[lanej]

@plribeiro3000 you mean in the main fog repository ?

[plribeiro3000]

@lanej Both in the main fog repository (regarding all providers) and in the providers (that are going to require at least fog-core and fog-json or fog-xml).
This 2 level of dependency might turn into a headache if we don't control the big picture.
Like latest fog-aws depends on fog-core ~> 1.27 while latest fog-whatever depends on fog-core >= 1.34. Then you wont be able to get latest of both providers because of that (which is the main idea behind having the main repo)

[lanej]

@plribeiro3000 My only concern would be backwards incompatible changes to the shared fog libraries (fog-core, fog-json, etc.). In that case wouldn't necessarily want the latest of the providers but I guess that is something you could coordinate.

If fog-aws required fog-core ~> 1.27 and fog-softlayer required fog-core >= 1.34, then there shouldn't be a conflict. As long as another dependency did not declare a need for a 2.x version.

[plribeiro3000]

@lanej True. So if there is backwards incompatible changes you should not pin to a version of fog-core but instead blacklist all the old versions that are not supposed to work against your latest version anymore (like >= 1.27.0)

IMO the main pain point is that is a lot of providers and having specific versions locked will just make it harder to maintain the whole thing together.

[lanej]

@plribeiro3000 unfortunately that's the tradeoff. Either you leave it very open and maybe run into some problems with core library changes later, or you restrict and have to coordinate all the dependencies.

[plribeiro3000]

@lanej Agreed. I think we should leave it open in a way that the final user has more control over it and leave us with less burden regarding that. The current pattern is doing restrictions and thus making us have to coordinate this whole thing all together.

What do you think about release the lock a little bit here?

[lanej]

My vote is still for the ~> but I'll defer to the broader organization.

[plribeiro3000]

@lanej Can we at least push it for a more uptodate fog-core version then?

[lanej]

@plribeiro3000 That works.

[plribeiro3000]

@lanej Awesome. Since you raised the point, would you be up to have a close eye on the fog-core and fog-json releases in fog-aws in a way that it will always stay uptodate?

I will try to do this for the other repos.

[lanej]

@plribeiro3000 ill slam the rubygems feed into my RSS reader. According to https://github.com/fog/fog-aws/blob/master/fog-aws.gemspec#L27 it is possible that some users have been grabbing the latest fog-core release.

[plribeiro3000]

Awesome. I would recommend following fog on twitter. =)