[DÚVIDA/DISCUSSÃO] Divagações sobre Versionamento de código

Contexto

Recentemente venho estudando formas de administrar projetos, principalmente no que diz respeito a convenções para commits e ferramentas (commitlint, comitzen), a pull request, padrões de escrita para pull request (dar um squash dos commits em PRs, ou dar rebase, etc...), e outras coisas.

Versionamento de Front-end

Dito isso, quero saber de você, quando a versionamento, como vocês versionam o código de vocês: ferramentas, convensões, CI/CD, etc... principalmente no que diz respeito a versionamento de websites, tenho essa dúvida a um tempo.

Para APIs uso a lógica do Semver(Versionamento Semântico):

Dado um número de versão MAJOR.MINOR.PATCH, incremente a:

1. versão Maior(MAJOR): quando fizer mudanças incompatíveis na API,
2. versão Menor(MINOR): quando adicionar funcionalidades mantendo compatibilidade, e
3. versão de Correção(PATCH): quando corrigir falhas mantendo compatibilidade.

Rótulos adicionais para pré-lançamento(pre-release) e metadados de construção(build) > estão disponíveis como extensão ao formato MAJOR.MINOR.PATCH.

Porêm como isso se aplicaria a uma plataforma web? até então venho usando a seguinte lógica:

1. versão Maior(MAJOR): quando fizer mudanças incompatíveis na API | Em frontend penso nisso como mudança grande que mude o geito como o site é construido, e.x.: Mudar de unified para contentlayer na hora de renderizar markdown e por ai vai.
2. versão Menor(MINOR): quando adicionar funcionalidades mantendo compatibilidade | qualquer alteração visual
3. versão de Correção(PATCH): quando corrigir falhas mantendo compatibilidade | Correção de bugs, falhas de segurança e atualização de pacotes

Estaria eu pensando da forma correta quando a versionamento de websites, vocês versionam seus projetos front-end? Pelos projetos que vejo, versionamento de projeto front-end não é muito comum, vide o próprio Tabnews que aparentemente não é versionado com 1.0.0, 1.2.0, 2.3.4-alpha.2, etc... Dissertem!

Tools

Agora sobre ferramentas, uso Tags do Git e Releases do Github, falando especificamente sobre projetos Node.js, desenvolvi eu mesmo uma solução com Deno, para assim que fizer um push no repositório, esse script roda em um Action do Github, lê a versão no package.json, cria um Tag no git, e da um push nessa Tag, para manter as Tags no Github sincronizadas com a versão do meu package.json, você pode encontrar essa solução nesse arquivo bump-tag-version.ts, e nesse arquivo bump-tag.yml.

Recomendam alguma ferramenta/workflow para auxiliar nesse quesito? Até mesmo para criar releases automáticas com autocomplete do corpo da nova Release.
Também uso o renovate-bot para atualizar automaticamente minhas dependências, e ele possui uma configuração para dar um bump na versão do package.json toda vez que atualizar uma biblioteca:

renovate.json

# ...
"bumpVersion": "patch",
# ...

No caso ai ele vai atualizar como um patch no package.json.

Compartilhem qualquer experiência, dica, links, artigo, ferramentas, convenções...