Versioni / versioni semantiche per applicazioni web

Question

Versioni / versioni semantiche per applicazioni web

#1 da (5 voti)
#2 da (3 voti)
#3 da (1 voti)

5

Quindi ho cercato e analizzato correttamente le versioni delle mie applicazioni piuttosto che elaborare il mio schema. Il versioning semantico è un'opzione popolare come probabilmente molti di voi conoscono, ma le mie applicazioni non si applicano realmente ai criteri semantici. Con questo voglio dire che il mio prodotto non è un'API. Guardando a questo, la gente dice che il versioning semantico è principalmente per le dipendenze.

Quindi la mia domanda è: esiste uno schema di versioning per qualcosa come un'applicazione web o come posso adattare il versioning semantico a me.

Ho trovato le seguenti cose che ho trovato: Quindi usa ancora 0.0.0 = x.y.z

z: MAJOR: modifica significativa dell'interfaccia utente o del codice e / o della struttura
y: MINORE: nuove funzionalità
z: PATCH. Correzioni di bug

Questo, per la maggior parte, sembra che funzionerà alla grande. Forse sto pensando profondamente ma quando spingo un cambiamento, non una correzione di bug o una nuova funzionalità, che cosa è considerato? Patch o minore? Ho appena ricevuto alcuni consigli su come eseguire correttamente la versione delle applicazioni web per un utente finale, non su un'API.

versioning

posta Munch 28.02.2018 - 11:11

fonte

3 risposte

Leggi altre domande sui tag versioning

Vantaggi delle applicazioni HTML in una intranet di Windows Raggruppamento di oggetti in base a una serie di campi

score 5 · Answer 1

Quale scopo avrà questo numero di versione per il tuo server di applicazioni Web? Ti sei chiesto se hai anche bisogno di un numero di versione?

Come consumatore di una libreria, un numero di versione è importante, specialmente se quella libreria adotta il controllo delle versioni semantico. Posso capire a colpo d'occhio quanto sia significativo un cambiamento di una nuova versione, a causa della semantica di major.minor.patch .

In quanto consumatore di un'applicazione desktop, i numeri di versione diventano tanto di marketing quanto mi dicono, l'utente, cosa è cambiato. La versione semantica diventa meno importante. MyApp 2018 trasmette istantaneamente la novità dell'app. MyApp v4, meno così. Oltre a vendermelo, probabilmente mi interesserebbe solo il numero di versione se avessi un problema e avessi bisogno di supporto.

Ora pensa alle app sul tuo telefono o tablet. Supponiamo che tu abbia installato l'app di eBay. Che versione è? Ti è mai importato? Sapresti come trovare il numero di versione senza assistenza dal supporto? Quella versione ora è lì per puro scopo di supporto.

Poi arriviamo alle app web. "Ehi supporto, ho un problema, OK, colpirò F5. Oh sì, è stato risolto. Grazie". Quindi chiaramente l'utente non ha più bisogno di un numero di versione. Quindi, poiché l'utente non ne ha bisogno, è necessario chiedere, ne hai bisogno per qualche motivo?

Se lo fai, allora per cosa? Cosa significherebbe un cambiamento di rottura? Vuoi registrare se hai appena introdotto correzioni di bug, miglioramenti o nuove funzionalità? O vuoi semplicemente un marcatore ad es. Git che registra quando è avvenuto un rilascio? È probabile che "v1", "v2", "v3" ... o anche "2018-02-28" si adatti alle tue esigenze.

score 3 · Answer 2

Perché usi il versioning semantico per la versione API? Per rendere più semplice per i tuoi utenti (qui "utenti" sono altri programmatori anziché tipici "utenti finali") per consumare l'API.

Quando usi una libreria, diciamo - libfoo , nel tuo progetto puoi aspettarti che:

quando esegui l'aggiornamento da 1.0.0 a 1.0.1 ci saranno solo correzioni di bug
quando esegui l'upgrade da 1.0.0 a 1.2.0 puoi aspettarti alcune nuove funzionalità minori (ad esempio, la libreria implementa ora un nuovo algoritmo Parallel_Foo invece di solo Foo ) o miglioramenti (ad esempio, la libreria dovrebbe essere ora un po 'più veloce)
quando esegui l'upgrade da 1.0.0 a 2.0.0 dovrai riscrivere il codice perché l'API potrebbe essere cambiata

Puoi utilizzare lo stesso ragionamento quando scrivi un programma per l'utente finale e rilasci una nuova versione.

Se la nuova versione contiene solo correzioni di errori, incrementa il numero z . Se la nuova versione contiene alcune nuove funzionalità (ad esempio la crittografia lato client delle immagini cat), incrementa il numero y . Se la nuova release interferisce con l'interfaccia utente e richiederà agli utenti di imparare di nuovo come utilizzare il programma, incrementa il numero x .

Un programma per l'utente finale ancora presenta un'interfaccia ("I" in API), l'unica differenza è che è un utente ... invece di < em> Interfaccia di programmazione dell'applicazione ... . Deve ancora essere consumato (solo dagli umani invece che dalle macchine), può cambiare e può essere retrocompatibile. Non sono poi così diversi.

score 1 · Answer 3

Se ..

Non ci sono API da utilizzare da altri sistemi esterni (non ora, non in futuro).
Oppure, ci sono API ma usate solo dal sito stesso
Oppure, non ci sono affatto API

poi ..

Non è necessario il controllo delle versioni. Il controllo delle versioni in questo caso è solo per te (lo sviluppatore), non è necessario seguire alcun modello di controllo specifico.

Se vuoi ancora la versione del tuo sito web, lo farei in questo modo (soluzione personalizzata):

pushdate_major.minor.patch

Esempio: 2018-08-15_1.3.2

In questo modo, puoi immediatamente sapere:

Quando è stata l'ultima spinta
Numero di modifiche importanti avvenute
Numero di modifiche minori alla versione principale corrente
Numero di patch per il rilascio secondario corrente