Version tags (especially for Docker images) often contain additional metadata about that entry in the repository. In most cases (at least that we care about) these are usually dash-separated tokens in the version, like python:3.6-alpine3.6.
In general we shouldn't automatically propose updates that would switch between different tags or "release trains". As an example, the bot generated an update to monasca-helm: https://github.com/monasca/monasca-helm/pull/185
In this case monasca-helm's client chart is using "released" image versions with standard semver tags (monasca/client:1.6.0 - we'd probably consider this a null tag) and the bot tried to update it to use monasca/client:master-20170918-185757 (master tag). Since monasca/client:1.7.0 was also published we should have used that release instead.
This introduces some problems:
determining tags for a version depends on the version number formatting (see also, versioning policies from #15)
we'd need to store multiple current versions for every module from every repository - latest version per tag
we'd also (maybe later) need some way to specify how+when dependencies actually receive updates (related to per-module configuration from #15). Behaviors might include:
semver-patch: only update z in x.y.z
semver-minor: either y or z in x.y.z
semver-major: always use latest available semver
semver-* could have additional policy options:
tagPolicy: sticky (default) only updates to matching tags (e.g. no updates to master from null), none ignores tags (current behavior)
tag: just lock to a particular tag
datever: (or something) use the tag with the latest embedded timestamp (for the master-{date}-{time} case)
Version tags (especially for Docker images) often contain additional metadata about that entry in the repository. In most cases (at least that we care about) these are usually dash-separated tokens in the version, like
python:3.6-alpine3.6.In general we shouldn't automatically propose updates that would switch between different tags or "release trains". As an example, the bot generated an update to monasca-helm: https://github.com/monasca/monasca-helm/pull/185
In this case monasca-helm's client chart is using "released" image versions with standard semver tags (
monasca/client:1.6.0- we'd probably consider this anulltag) and the bot tried to update it to usemonasca/client:master-20170918-185757(mastertag). Sincemonasca/client:1.7.0was also published we should have used that release instead.This introduces some problems:
semver-patch: only updatezinx.y.zsemver-minor: eitheryorzinx.y.zsemver-major: always use latest available semversemver-*could have additional policy options:tagPolicy:sticky(default) only updates to matching tags (e.g. no updates tomasterfromnull),noneignores tags (current behavior)tag: just lock to a particular tagdatever: (or something) use the tag with the latest embedded timestamp (for themaster-{date}-{time}case)last-published: current behavior