This fixes shards outdated to work correctly with non-release versions. Currently it reports every version as outdated which is not the latest release, even if the installed commit is ahead of the latest release.
Resolves #446
In the example from #446, it's pretty obvious: The installed version is head on master, so it's really the latest and should not be listed as outdated.
When the requirement is a branch, the intention is to track that path. So the highest available version is head of that branch.
If there is a tagged releases with a higher version number (independent of the requirement restriction), that should always be treated as latest.
Commit and tag requirements are complicated because they provide no context to depict intention. A typical use case would be to pin an unreleased commit in master.
For now shards outdated assumes available versions for a tag or commit requirement to be on master branch.
Further enhancements could look whether the commit is actually an ancestor of master. That could help identify a pinned commit not merged to master. But there's not really a point forward from there, anyways. So it's probably fine to leave it that way.
There is currently a limitation that the requirements can only be accessed for first level dependencies. shards outdated just grabs that from shard.yml. For transitive dependencies I couldn't find an easy way to access the dependency requirement because there can be multiple ones and the solver just merges them together.
This only makes a difference when a dependency has a dependency with a branch restriction. Then the special handling for reporing branch head as available version does not work.
This can probably be improved later, but for now the fix is good enough and doesn't need to cover all edge cases.
This has already proven very valuable in practice, because it removes a lot of noise from shards outdated.
This fixes
shards outdatedto work correctly with non-release versions. Currently it reports every version as outdated which is not the latest release, even if the installed commit is ahead of the latest release.Resolves #446
In the example from #446, it's pretty obvious: The installed version is head on
master, so it's really the latest and should not be listed as outdated.When the requirement is a branch, the intention is to track that path. So the highest available version is head of that branch.
If there is a tagged releases with a higher version number (independent of the requirement restriction), that should always be treated as latest.
Commit and tag requirements are complicated because they provide no context to depict intention. A typical use case would be to pin an unreleased commit in master. For now
shards outdatedassumes available versions for a tag or commit requirement to be on master branch. Further enhancements could look whether the commit is actually an ancestor of master. That could help identify a pinned commit not merged to master. But there's not really a point forward from there, anyways. So it's probably fine to leave it that way.There is currently a limitation that the requirements can only be accessed for first level dependencies.
shards outdatedjust grabs that fromshard.yml. For transitive dependencies I couldn't find an easy way to access the dependency requirement because there can be multiple ones and the solver just merges them together. This only makes a difference when a dependency has a dependency with a branch restriction. Then the special handling for reporing branch head as available version does not work. This can probably be improved later, but for now the fix is good enough and doesn't need to cover all edge cases.This has already proven very valuable in practice, because it removes a lot of noise from
shards outdated.