Esiste uno schema equivalente di Versioning semantico per software non API?

Question

Mi piace molto lo schema di Versioning semantico, ma in realtà ha senso solo per le API, poiché l'attenzione è rivolta alle interruzioni delle modifiche e alla retrocompatibilità. Per le non-API, ad es. software per l'utente finale, molte delle regole non hanno più molto senso. Ad esempio, il concetto stesso di retrocompatibilità non significa veramente nulla; l'utente sperimenta nuove funzionalità o non lo fa, meno bug o non lo fanno, ecc. Trarrebbe comunque vantaggio da uno schema chiaro per il controllo delle versioni di xyz che segue lo spirito del versioning semantico in modo che gli utenti possano avere qualche idea su cosa aspettarsi dai nuovi numeri di versione se hanno familiarità con lo schema.

ho provato a disegnare qualcosa come:

• Bump z se apportare modifiche interne al codice (ad esempio correzioni di bug, il refactoring) che non cambiano l'esperienza dell'utente. Può includere nuove funzionalità "interne".
• Bump y se si aggiungono funzionalità che cambiano l'esperienza utente al di là delle correzioni di bug alle funzionalità correnti.
• Bump x ... ??? ... cambiamenti radicalmente diversi nell'esperienza utente? Cosa è radicalmente diverso? verifica
• sviluppo alfa iniziale come 0.0.z
• Prima pubblicazione beta-testing è impostato 0.1.0 e rimane 0.yz
• rilascio Primo utente è impostato 1.0.0

Un'altra l'idea è di fare x colpi quando le caratteristiche che sono rimosse poiché alcuni utenti potrebbero fare affidamento su di loro, ma che in alcuni casi potrebbe sembrare ingiustificato. (Dite di conoscere tutti gli utenti e tutti vogliono una funzionalità molto piccola rimossa. Passare da 1.0 a 2.0 sarebbe alquanto controintuitivo.)

Questo è più soggettivo rispetto al controllo di versione semantico perché è molto più facile da identificare oggettivamente funzionalità compatibili con le versioni precedenti e funzionalità di rottura delle API. Esistono schemi di controllo delle versioni "standardizzati" che potrei esplorare per maggiore assistenza?

Answer 1

Se il software salva i file di dati o legge i file di configurazione, quindi al minimo il formato di questi file è la vostra "API" e quindi cambia in quel formato sarebbe in linea di principio giustificare urtare X.

Answer 2

Sono stato cercando qualcosa di simile, ma non ho trovato nulla di "ufficiale". Ecco come ultimamente ho fatto la numerazione delle mie versioni.

Dato x.y.z

• x = Incremento ogni volta che si riprogettazione l'esperienza dell'utente. Ad esempio, è possibile riorganizzare le cose sull'interfaccia principale come il modo in cui Microsoft ha fatto con Office 2003 rispetto al 2007. Se l'applicazione memorizza i file o le impostazioni dell'utente, questo numero dovrebbe anche essere incrementato se le modifiche non saranno retrocompatibili con il vecchio file o impostazioni.

• y = Fondamentalmente incrementare ogni volta che si aggiunge una nuova subroutine/funzione. Generalmente cose come l'aggiunta di una nuova voce di menu o di un pulsante rientrano in questa categoria poiché dovrai scrivere una richiamata per gestire l'evento click sulla voce di menu o sul pulsante. Un altro esempio potrebbe essere qualsiasi modifica al codice che non apporti una differenza evidente all'utente, ma migliora la gestibilità (ad es.finalmente sei riuscito a scrivere un corso per gestire il tuo file delle impostazioni). Reimposta questo numero se x viene incrementato.

• z = Incremento ogni volta che si corregge un bug. Reimposta questo numero se x o y viene incrementato.

Nota: Personalmente, mi piace pensare che se si ottiene y in numeri a due cifre, è il momento di prendere in considerazione una riprogettazione dell'interfaccia utente che avrebbe portare a un incremento di x.