Closed Blacksmoke16 closed 3 years ago
That is the expected behavior.
x.y.z
is exactly that version~> x.y.z
needs to be used if you want to allow patch updates~> x.y, >= x.w.z
needs to be used if you want to allow minor updates, since some specific minor.Also, since shards packages do not need to follow semver, we can't assume that x.y.z+1 should be a safe replacement for x.y.z.
@bcardiff But these dependencies are defined with ~> 0.2.2
. https://github.com/athena-framework/athena/blob/v0.12.0/shard.yml#L28. So I guess my question is why does it install 0.2.3
when 0.2.4
should totally be a valid version given I'm allowing patch updates, and it's a published release.
I would suspect the cause to be hat the new 0.2.4 releases have athena-framework/config
restricted to ~> 0.2.0
so that would not be compatible with the restriction ~> 0.1.3
on that dep in other dependencies.
@straight-shoota Ohh you would be exactly right. In that case 0.2.3
is the correct version. Going to close as this is expected.
It would probably be nice if shards could share some insights why a newer version can't be selected. At least when running shards outdated
. I'd expect that to not be trivial, though. Don't know if other dependency managers have such a feature.
I see, sorry @Blacksmoke16 for misreading the issue.
@straight-shoota IIRC rubygems have it.
I may be missing something as it's late, but I noticed when doing a shards install/update, it's not installing the latest version of that shard's dependencies.
With a
shard.yml
like:Running
shards install
produces the following lock file:I would have expected the serializer and dependency injection shards to be updated to
0.2.4
as I recently released those versions, and they are defined asversion: ~> 0.2.2
in Athena'sshard.yml
. If installing either the dependency injection shard or the serializer on their own, the correct version of0.2.4
is used within the lock file.EDIT: Tested with both
0.12.0
and0.13.0
.