Versioning semantico per applicazioni desktop [duplicato]

Il versioning semantico sembra essere in conflitto con la maggior parte della numerazione delle applicazioni desktop. Abbiamo risolto questo problema consegnando il "versioning del prodotto" al reparto marketing e manteniamo versioni completamente separate (ma logiche per noi) per tutti i componenti. Una versione specifica del prodotto diventa quindi una raccolta definita di componenti compatibili. Mantenere il controllo delle versioni semantiche tra i componenti è molto più semplice.

Ho adattato il versioning semantico per applicazioni desktop o web, quindi nel nostro lavoro stiamo usando: X.Y.Z

1. Z sta aumentando se una versione contiene solo una correzione di bug, un aggiornamento delle dipendenze o alcune modifiche interne all'applicazione, quindi nessuna nuova funzionalità è stata introdotta all'utente;
2. Y sta aumentando se una versione contiene modifiche minori nell'interfaccia utente o introduce solo alcune nuove funzionalità o qualche aggiornamento di funzionalità / riprogettazione delle funzionalità che interesserà l'utente;
3. X sta aumentando se una versione contiene un aggiornamento dell'interfaccia utente / funzionalità principale, ad esempio: nuova progettazione dell'interfaccia / layout;
4. Il nuovo progetto inizia con la versione 0.1 e la versione secondaria aumenta con lo sviluppo;
5. Se un progetto contiene tutte le funzionalità pianificate per la versione 1.0, la versione deve essere modificata in 1.0.

Vecchio post, ma stavo cercando una soluzione e sono incappato in questo articolo di Brett Uglow ( permalink ) che è la cosa migliore che abbia mai letto sulle applicazioni di versioning che verranno consegnate direttamente agli utenti finali, in particolare le applicazioni desktop.

Un estratto dell'articolo:

...

The installer-user

The installer-user is the person who has to install the application. To them, the “public API” of the application is the installation-requirements. But who is the installer-user?

For the Twitter mobile app and desktop app, the installer is (usually) the end-user. The installation-requirements would be a minimum required version of the operating system and an internet connection.

For the Twitter web application, the installer is someone from the DevOps (or Operations) team. They care deeply about the installation-requirements as they need to provision the correct infrastrucure based on these requirements.

Proposal

Given the importance of the installation-requirements of an application to installer-users, I propose that semver be used to version end-user applications using the installation-requirements as the public API with installer-users as the consumers of this API.

In practice, increment the:

• MAJOR version when you make incompatible API changes (e.g. installer-users have to modify their infrastructure (phone/tablet/PC/web-server/firewall config/etc) in some way),

• MINOR version when you add functionality in a backwards-compatible manner (e.g. passing additional data to an already-provisioned API or adding any end-user functionality that does not affect the installation-requirements), and

• PATCH version when you make backwards-compatible bug fixes (e.g. fixing any end-user bug that does not affect the installation requirements).

By treating the installer-users as the consumers of an end-user application, and the installation-requirements as the public API, I believe that semver does make sense and is valuable as a communications mechanism for end-user applications.