Le regole di controllo delle versioni semantiche sono applicate al tuo software dal punto di vista dei tuoi utenti. Se la tua API è cambiata e non è retrocompatibile, devi aggiornare il numero di versione principale. Sembra che questo non sia il caso, però. Sembra che la tua API non sia cambiata: i clienti che stavano usando la tua versione precedente possono semplicemente abbandonare la nuova versione senza altre modifiche. Questo sarebbe un aumento di versione minore.
Ciò è confermato nel FAQ sulla versione semantica :
What should I do if I update my own dependencies without changing the
public API?
That would be considered compatible since it does not affect the
public API. Software that explicitly depends on the same dependencies
as your package should have their own dependency specifications and
the author will notice any conflicts. Determining whether the change
is a patch level or minor level modification depends on whether you
updated your dependencies in order to fix a bug or introduce new
functionality. I would usually expect additional code for the latter
instance, in which case it’s obviously a minor level increment.
In base ai commenti, sembra che si stia utilizzando il Versioning semantico per un'applicazione. Questo non è un tipico caso d'uso. Il versioning semantico è progettato per API e librerie. Un'altra domanda qui su Software Engineering Stack Exchange affronta l'uso di Versioning semantico nelle applicazioni .
Nell'istanza di un'applicazione basata su GUI, la GUI è la tua interfaccia pubblica. Vorrei usare definizioni come questa:
- Versione MAJOR quando apporti modifiche al flusso di lavoro di un utente o in che modo gli utenti interagiscono con il tuo software in modo non compatibile con le versioni precedenti.
- Versione MINORE quando aggiungi funzionalità in modo compatibile con le versioni precedenti
- Versione PATCH quando si apportano correzioni di bug compatibili con le versioni precedenti.
Se aggiungi funzionalità senza modificare flussi di lavoro esistenti, è una versione secondaria. Se si modificano i flussi di lavoro esistenti, è una versione principale. Le versioni di patch sono correzioni di bug che non cambiano il modo in cui gli utenti interagiscono con il tuo software.