come si applica la versione semantica ai programmi senza API

In http://semver.org/ —che secondo la mia percezione sembra essere la convenzione più utilizzata nel controllo delle versioni — si consiglia di aumentare il numero di versione principale quando viene introdotto un cambiamento che interrompe / modifica l'API.

Esistono due scenari correlati, ma non vedo come applicare questa linea guida:

1. Cosa succede se il mio codice non offre alcuna API? Come devo versione il mio codice?
2. Cosa succede se il mio codice inizia a offrire un'API in una fase avanzata del suo sviluppo?

Semver è principalmente preoccupato per il controllo delle versioni di librerie e pacchetti in un modo che evita l'inferno delle dipendenze, nelle sue varie incarnazioni. Tuttavia, l' idea alla base di Semver può essere estesa a tutti i tipi di programmi: qualsiasi parte di codice ha una sorta di interfaccia utente o è piuttosto inutile.

• Una libreria di programmazione o un servizio Web ha un'API.
• Il software di consumo potrebbe avere una GUI.
• I programmi della riga di comando hanno una serie di opzioni e opzioni.
• I file di configurazione sono anche un'interfaccia utente.

Utilizzando l'esempio del software consumer, come un elaboratore di testi:

• Aumentare il numero di patch quando si invia una correzione di bug, ad esempio: " bug risolto in cui l'applicazione si blocca sempre alle 00:00 di martedì ".
• Aumenta il numero di versione secondario quando aggiungi una nuova funzione, ad esempio: " aggiunto supporto per il testo sottolineato ".
• Incrementa la versione principale quando rivedi in modo significativo l'interfaccia utente o riscrivi tutti gli interni. Ad esempio: “Le barre degli strumenti utilizzano troppe proprietà dello schermo. L'interfaccia utente viene ora fornita solo tramite gesti tattili ": una modifica del genere interromperebbe i flussi di lavoro esistenti.

Tuttavia, molti problemi che Semver cerca di risolvere non esistono al di fuori dell'area della gestione delle dipendenze. Nelle applicazioni consumer, la versione non è solo una versione, ma anche una risorsa di marketing.

• Firefox e Chrome rilasciano nuove versioni relativamente frequentemente e incrementano il loro numero di versione principale ad ogni versione. Ciò si traduce in numeri di versione ridicolmente alti (entrambi sono attualmente sulla trentina). Un browser con un numero di versione superiore deve semplicemente essere migliore di un browser con un numero di versione inferiore, giusto?

• Il numero di versione principale del sistema operativo Apple OS X è diventato parte del nome (X è 10 in numeri romani), rendendo il numero di versione minore il numero di versione maggiore effettivo.

• Il sistema operativo Ubuntu utilizza uno schema di versioning year.month.patchlevel. Questo rende facile ricordare quanti anni ha il tuo sistema operativo, ma rende molto più difficile capire quali versioni sono compatibili e quanto dura il supporto per ciascuna versione.

• Il kernel di Linux ha aumentato il numero di versione dalla 2.6.39 alla 3.0.0, perché 39stava diventando un po 'grande e per commemorare il 20 ° anniversario di Linux.

• Il leggendario sistema di composizione TeX di Donald Knuth utilizza un numero di versione che, a partire dalla versione 3, converge in π aggiungendo un'altra cifra ad ogni versione: 3.14159265…. Questo significa come il sistema si sta avvicinando alla perfezione. Allo stesso modo, il sistema Metafont converge in e : 2.7182818….

Quindi, molte applicazioni non sono ben servite da Semver. Scegli uno schema di versione adatto ai tuoi utenti (indipendentemente dal fatto che questi siano colleghi programmatori o consumatori) e mantienilo coerente.