Não importa realmente se é uma biblioteca ou uma aplicação maior. Um esquema de versionamento semântico funciona perfeitamente bem para uma aplicação grande. Ele pode até ser usado para uma coleção de aplicações empacotadas em uma plataforma, mas aqui se torna bastante difícil de lidar.
A principal questão é se você vai seguir o caminho da depreciação suportada em uma versão e apenas a remoção dela na próxima principal. Ter funcionalidade depreciada, mas suportada, pode exigir bastante esforço. Quando você vai fazer alterações em seu modelo de dados persistido, a depreciação pode se tornar impossível. Se isso acontecer, você nem consegue fazer uma versão menor com funcionalidade depreciada e salta instantaneamente para a próxima principal. Esta é a parte onde aplicações grandes geralmente têm problemas. Você passa de 3.0.0 para 3.0.1 para 4.0.0 porque não consegue fornecer retrocompatibilidade. Se você frequentemente tem alterações que quebram a compatibilidade, aderir ao semver agrega pouco valor.
Dito isso, eu prefiro muito mais essa construção porque comunica mais claramente aos desenvolvedores que haverá alterações que quebram a compatibilidade. O esquema YYYY.N não me diz nada como desenvolvedor, e nada como administrador.
Então a questão é, o que você quer comunicar com a versão? Se você quer fazer 6 lançamentos de recursos (que podem ou não quebrar a compatibilidade), e a cada 6º lançamento será mais longo suportado com correções; e você não quer versionar lançamentos de correções. Então X.Y é um esquema adequado onde Y=0 é o mais longo suportado. X seria apenas um número. O problema é quando X é o ano, então Y é rapidamente associado a um mês. Então lançamentos mais novos e mais longamente suportados serão lançados em janeiro? Eu sempre tenho que procurar qual versão do Ubuntu é uma LTS, o que me incomoda.
Então, e se o Discourse simplesmente continuar com a versão principal atual. A próxima versão mais longa suportada é chamada 4.0; e então teremos 4.1 a 4.5 como lançamentos de recursos; seguidos por 5.0 que é o mais novo e mais longo suportado.
Então você também não terá aquele momento estranho em que um lançamento é atrasado por causa de um problema importante.
Você pode opcionalmente adicionar um número de “correção” se planeja lançar correções explicitamente (em vez de ter correções contínuas). “Mas então você terá x.y.z que é semver”. Bem, não, parece semver, mas não é. Cada nova versão “menor” pode quebrar a compatibilidade. Então eu sugiro apenas aderir ao esquema X.Y como esquema de versão com Y=0 → LTS.
Deixando a string de versão de lado. Eu gosto do novo plano de lançamento.