Add rolling semver tags, remove latest tag

[pat-s]

fix #4597 fix #3131

• Removing latest tag to avoid automatic major release upgrades
• Add rolling tags for major and minor release versions (allows semi-automated upgrads and prevents from direct major upgrades)

[qwerty287]

What will happen if we publish a release like 2.10.0?

[pat-s]

Oh dear, good point 🙈️

Changed it to the following

CI_COMMIT_TAG="v2.10.0"
short_tag=${CI_COMMIT_TAG%.*}
echo "$short_tag"
v2.10

[qwerty287]

And what about 10.0.0? Same thing…

[qwerty287]

And docs must get an update: https://woodpecker-ci.org/docs/administration/deployment-methods/docker-compose#docker-images

[woodpecker-bot]

Deployment of preview was torn down

[anbraten]

3.0.0.rc.0 and other rc versions would still override major versions as explained in #4597.
Can't get why we need to drop latest. We could suggest people to use pinned version, if they want to use latest fine.

[pat-s]

3.0.0.rc.0 and other rc versions would still override major versions as explained in #4597.

Sure but in this case users opted in to use this version on purpose and not by getting a background update due to a rolling tag.

Can't get why we need to drop latest. We could suggest people to use pinned version, if they want to use latest fine.

Even though some/most might do, the "a major upgrade happened and everything broke" issues will never stop this way, also because people often don't set a tag at all and hence will get latest implicitly.
By removing latest, you workaround this problem actively by forcing users to specify a tag they want.

If you think about it, why should there ever be a tag crossing major version automatically? This will always result in a functional disaster. Admins have to adjust the config anyhow for a major upgrade, so arguing with "it reduces admin work" doesn't work. But it pro-actively prevents issues for admins and issues posted to the project. Does that make sense?

[IamIpanda]

people often don't set a tag at all and hence will get latest implicitly.

That's reasonable, so may I know why latest-alpine tag also stop update? People, or at least I, choose this tag and that means I know what I will get.

Let me say it: Not everyone work for a big woodpecker with an admin, more people just leave an instance, write some script and never open it then. The only result of dropping latest is that they will NEVER KNOW there is version 3 because woodpecker Is just a small app in their long list and the pull error will be ignored. Sure they will keep in version 2 and work for several years and even never complains. That's why I reply that 2 months later. Not everyone keeps an eye on github and docker hub.

I still want a stable tag use latest stable version, not CD one. It's fine it don't name latest. It's fine it will blow up. Without blowing up I'm still using DRONE_CI environment variables.

[pat-s]

A rolling tag across major versions would have likely meant that your CI stopped working silently for that period you didn't watch it.

Not matter if large or small instance, removing it helped you just now to not break your pipelines.

While not every major release might be "as breaking" as the previous ones were, I still think this is the best way forward.

Once established, users know it and the scenario above won't occur. You are free to check for new upgrades whenever it fits. Until then, this policy protects you.

An additional side effect is that people won't start with latest, protecting them from being unable to downgrade to the latest release due to DB schema migration.

[IamIpanda]

A rolling tag across major versions would have likely meant that your CI stopped working silently for that period you didn't watch it.

Not matter if large or small instance, removing it helped you just now to not break your pipelines.

While not every major release might be "as breaking" as the previous ones were, I still think this is the best way forward.

Once established, users know it and the scenario above won't occur. You are free to check for new upgrades whenever it fits. Until then, this policy protects you.

An additional side effect is that people won't start with latest, protecting them from being unable to downgrade to the latest release due to DB schema migration.

Not everyone work with a big woodpecker which can't break.
Not everyone keep an eye for github for upgrade. What I only do is executing docker pull.
Not everyone use watchtower.
let me repeat, for me, BRAEKING IS EXPECTED, I don't know there is update is not expected.
Let me take that as an example: I use Arch.

Sure people shouldn't take latest tag in this scene, but I don't want next tag because that's a CD version. I want just a simple latest stable version tag, even though its upgrade will break my pipelines, because I'm not a heavy user, woodpecker break down for several days won't kill me. Do you really want to stick on an old version woodpecker which still integrate DRONE_CI variables?

I will move to v3-alpine. Please just take words below as a moment of angry.