Docker tag usage

[ramonsmits]

I just started using the container images and noticed updates on latest but not see any new releases:

https://hub.docker.com/r/dutchcoders/transfer.sh/tags

https://github.com/dutchcoders/transfer.sh/releases

Related to:

• Support Docker major / minor version tags #640

[paolafrancesca]

hey @ramonsmits , thanks for point out this.

https://github.com/dutchcoders/transfer.sh/blob/main/.github/workflows/build-docker-images.yml

there's edge, updated with the latest commit. and nightly, build every midnight UTC. latest point to both

latest point to latest build, and not latest tagged release. i guess that's the misunderstanding on your expection

the -nonroot prefix refers to a special build that can run as non root user: please see here for details, #418

README was updated to contain information in the same PR

do you have enough information to properly complete this PR? :)

[paolafrancesca]

please, add a bit about somthing like "not the latest released version, but the latest build that ever happened".
Also rephrase the "WatchTower" part about being careful about using "latest" since it points to not released versions. Since I can see that someone can still want to have WatchTower and "latest" or "edge" ("nightly" is not really the case, but who knows? :))

my personal take is that is as much safe to use "latest" as to use a tagged release. there's not enough test coverage for both, so we put extra care before merging anything to main, because i don't like to break main anyway. on top of that, the repo is anyway going through a lot of slow paced and few PRs and we do release with not exact plan as other than: there's enough stuff that's meaningful to tag something (minor), or we fixed a bug and we must release a patch version

There's a typo in "User an actual": "Use an actual"

[ramonsmits]

In that case you might want to consider tagging such builds with an actual pre-release tag like 1.7.0-preview.1

https://semver.org/#spec-item-10

AFAIK as I understood your feedback is that latest can point to any CI build. I would only want to auto-upgrade to newer versions and potentially be open to even upgrade to newer pre-releases

It also depends on how strict you following semver.

for example, besides the tag 1, there could be a tag 1- that indicates it will reference latest (pre) release while 1 only referenced latest release tag.

As a user I would not want to just deploy ANY commit on main/master. Only those consider relatively stable. For example, I'm using it only for personal reasons so I would be open to run preview releases but lets say I'm running 1- but you've released 2.0.0 with a breaking change that might requires me to update my container configuration... I definitely don't want to auto upgrade to that.

For me as a user, a pre-release tag would state a sort of minimum quality assurance AND it being the latest version.

[paolafrancesca]

please, check my comments and thank you for the effort in contributing 🙏