come si applica la versione semantica ai programmi senza API

Question

come si applica la versione semantica ai programmi senza API

#1 da (37 voti)

35

Nel link - che nella mia percezione sembra essere la convenzione più diffusa nel versioning- si consiglia di aumentare il numero di versione principale quando viene introdotta una modifica che interrompe / modifica l'API.

Ci sono due scenari correlati che non vedo come applicare questa linea guida:

Cosa succede se il mio codice non offre alcuna API? Come dovrei modificare il mio codice?
Che cosa succede se il mio codice inizia a offrire un'API in una fase avanzata del suo sviluppo?

semantic-versioning

posta Mario 02.09.2014 - 21:35

fonte

1 risposta

Leggi altre domande sui tag semantic-versioning

Lo sviluppo di Java comporta in genere più sottoclassi di C # /. NET? Come faccio a testare un sistema in cui gli oggetti sono difficili da schernire?

score 37 · Answer 1

Semver è principalmente interessato alla versione di librerie e pacchetti in modo da evitare l'inferno di dipendenza, nelle sue varie incarnazioni. Tuttavia, l'idea di dietro Semver può essere estesa a tutti i tipi di programmi - qualsiasi parte di codice ha un qualche tipo di interfaccia utente, oppure è piuttosto inutile.

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

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

Incrementa il numero di patch quando spedisci una correzione, ad esempio " bug corretto in cui l'applicazione si arresta sempre alle 00:00 PM di martedì ".
Incrementa il numero della versione secondaria quando aggiungi una nuova funzione, ad esempio " supporto aggiunto per il testo sottolineato ".
Incrementare la versione principale quando si modifica in modo significativo l'interfaccia utente o si riscrivono tutti gli interni. Ad es .: " Le barre degli strumenti utilizzano troppe proprietà dello schermo. L'interfaccia utente viene ora fornita solo tramite gesti tattili "- tale modifica interromperà i flussi di lavoro esistenti.

Tuttavia, molti problemi che Semver tenta 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 nel loro 30s). 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 principale efficace.
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 tempo dura il supporto per ogni versione.
Il kernel di Linux ha superato il numero di versione dalla 2.6.39 alla 3.0.0, perché 39 stava diventando un po 'grande e per commemorare il ventesimo anniversario di Linux.
Il leggendario sistema di composizione TeX di Donald Knuth utilizza un numero di versione che, a partire dalla versione 3, converge a π aggiungendo un'altra cifra ad ogni versione: 3.14159265 .... Ciò 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 controllo delle versioni adatto agli utenti (indipendentemente dal fatto che questi utenti siano colleghi programmatori o consumatori) e mantenerlo coerente.