La rapida versione principale mostra una prova di un design scadente?

16

Ho iniziato a lavorare come programmatore junior qualche mese fa. Il sistema su cui stiamo lavorando è in produzione da circa 2 anni. Non ero coinvolto nell'accattonaggio del sistema e del design.

Una cosa che ho notato è che la versione principale del sistema è già 11.YZ Dalla mia esperienza di lavoro con altri sistemi e librerie, non ricordo di aver visto un prodotto lanciare una versione maggiore così velocemente. Ci sono prodotti che esistono da anni in 1.XY e continuano a ricevere funzionalità e correzioni di errori.

Supponendo che il controllo delle versioni semantico sia utilizzato correttamente, ciò indica che il sistema è progettato in modo inadeguato dal momento che apporta importanti cambiamenti di rottura quasi ogni quattro mesi?

versioning semantic-versioning

— user367035
fonte

2

Tale domanda dipenderà dal fatto che tali importanti cambiamenti di rottura apportino abbastanza benefici (e profitti) che giustificano l'alto tasso di cambiamento.

— rwong

3

Se quel numero di versione utilizza Semver e se il sistema dispone di una libreria o di un'altra API da cui dipendono altri team o organizzazioni, questo elevato numero maggiore indica che ci sono stati problemi a impegnarsi in una progettazione API stabile ed estensibile. Significa anche che le incompatibilità comunicative chiare sono molto apprezzate, il che è positivo. Per qualsiasi altra cosa (come nomi di marketing, programmi applicativi, numeri non di Semver, ...) il numero è insignificante e dovrebbe essere ampiamente ignorato. Chiedi ai tuoi colleghi di questo, come parte di te per conoscere meglio il progetto.

— amon

3

@amon Il sistema viene utilizzato internamente con client mobili pubblici che comunicano con il sistema tramite API simili a REST. Il controllo delle versioni è Semver come ho già detto e non la versione di marketing.

— user367035

Il numero non ha importanza, ma sarei sospettoso se l'identificatore della versione includesse un acronimo carino, come Windows NT o Windows ME o XP o davvero Windows.

— John Wu,

1

@JohnWu: la questione è specificamente circa il numero, quindi, sì, il numero non importa. Più precisamente, si tratta del numero nel contesto di SemVer, in cui il numero non solo ha importanza, ma ha anche un significato specificato con precisione.

— Jörg W Mittag,

14

Supponendo che il controllo delle versioni semantico sia usato correttamente, ciò indica che il sistema è progettato in modo inadeguato dal momento che apporta importanti cambiamenti di rottura quasi ogni quattro mesi?

Non necessariamente.

Nei commenti hai menzionato che si tratta di un'API interna. Rompere un'API è male, perché infrangi il codice di tutti. Ma per un'API interna "tutti" sei solo "tu" e sei perfettamente in grado di coordinare tali cambiamenti API con te stesso, quindi il dolore che di solito è associato ai cambiamenti API è molto meno peggio.

Inoltre, la media potrebbe essere ingannevolmente ingannevole: forse hanno avuto 11 modifiche API rivoluzionarie durante i primi due giorni di sviluppo iniziale e da allora sono rimaste stabili per 4 anni? SemVer ti consente di apportare modifiche sostanziali senza aumentare il numero maggiore se il numero maggiore è 0, ma non ti obbliga a farlo. Forse hanno iniziato a utilizzare SemVer dal giorno 0, anche durante le fasi di prototipazione / esplorazione?

— Jörg W Mittag
fonte

5

Questa risposta sembra indirizzare direttamente la domanda. Alcune delle altre risposte sarebbero valide se non fosse per l'assunzione da parte dell'OP del versioning semantico.

— joshp

È anche degno di nota il fatto che le modifiche non sono sempre importanti. A volte sono davvero piuttosto piccoli (ma importanti). Quindi potrebbero aver bisogno di pochissimi cambiamenti per gli utenti. Inoltre, ci possono essere abbastanza grandi cambiamenti di rottura a seconda di come viene utilizzata l'API. A volte, una modifica non influisce su tutti gli utenti, ad esempio. Inoltre, le correzioni di bug possono introdurre modifiche di rottura, ma è l'ideale per risolverle prima piuttosto che dopo. E se l'API è interna, è molto più semplice gestire queste piccole modifiche.

— Kat

1

Risposta breve

No

Risposta lunga

"A volte un numero è solo un numero"

Dimentica "versione semantica", "razionalità", "logica" nell'attuale mondo pazzo

Perché Chrome acquisisce i numeri di versione così rapidamente?

i numeri della "versione" sono usati come pietre miliari per i punti di diramazione, non per le versioni principali per stupire il pubblico nel modo in cui gli altri sviluppatori li usano. Ed è un flusso di sviluppo in corso, con funzionalità pronte o non pronte, piuttosto che un evento occasionale che riunisce molte nuove funzionalità per creare un grande evento

— Tasso pigro
fonte

7

L'OP ha affermato che stanno utilizzando il versioning semantico; perché lo ignori?

— Jörg W Mittag,

-3

Quando si utilizza il controllo delle versioni semantico, è ancora necessario decidere quali modifiche sono considerate "maggiori" e quali "minori". Esistono vari motivi per eliminare il numero di versione o per non modificarlo.

I sistemi con promesse di compatibilità con le versioni precedenti potrebbero finire per aumentare il numero di versione principale con la maggior parte degli aggiornamenti, solo perché si verifica un'interruzione della compatibilità con le versioni precedenti in alcuni casi angolari più o meno esoterici. Gli stessi sistemi potrebbero rimanere fedeli a 1.xy quasi indefinitamente, perché molti sforzi vengono fatti nella compatibilità con le versioni precedenti, cercando di non rompere mai alcun sistema dipendente. Entrambi gli approcci alla numerazione delle versioni potrebbero essere considerati "conservativi", ma entrambi potrebbero anche essere un segno di un profondo problema di fondo.

Altre volte, in realtà hai una pianificazione di rilascio (pensa ai CD di aggiornamento trimestrali inviati ai clienti) in cui ha senso cambiare il numero di versione principale, in modo che invece di "Versione 3.4 / 16 ottobre" dica solo "Versione 11.0". Al giorno d'oggi, sempre più software viene rilasciato a brevi intervalli, rendendo i programmi di rilascio meno un motivo per attenersi a uno schema di versione specifico. L'ho visto nei grandi sistemi di magazzino che consentono all'IT interno solo un giorno di inattività un quarto (di solito una domenica). Questo giorno è il giorno della distribuzione ed è sempre contrassegnato da una nuova versione principale.

Alcuni programmi hanno dipendenze esterne di estrema importanza, poiché l'utente dovrà aggiornarli entrambi contemporaneamente. Se si dispone di un componente aggiuntivo di Word che funziona solo con Word 2010 e un altro per Word 2013, è possibile che si desideri sincronizzare i numeri di versione principali con quelli di MS-Word. Qui, i numeri principali sono così importanti, perché alcuni dei tuoi utenti saranno "indietro" nella normale pianificazione degli aggiornamenti, dal momento che non hanno aggiornato la versione più recente di Word (o qualsiasi altra cosa su cui fai affidamento: SAP, Dynamics, eccetera).

A volte, altri fattori esterni determinano i numeri di versione. Se si dispone di software fiscale, potrebbero esserci aggiornamenti annuali corrispondenti alla normativa fiscale (che tende ad entrare in vigore il 1 ° gennaio). Tali sistemi avranno versioni principali che cambiano esattamente una volta all'anno, non perché questo sia il programma di aggiornamento, ma perché questo è di altra importanza per il cliente: se fai le tasse del 2016, è meglio che tu abbia un programma aggiornato alla legislazione fiscale del 2016.

Alla fine, i numeri di versione dipendono da così tanti fattori - spesso specifici di un dominio - che il numero da solo non ti dice nulla sullo stato della tua base di codice. È un approccio molto migliore per vedere quando, perché e come avvengono le distribuzioni - e con che facilità. Se riesci a distribuire un aggiornamento importante a 10.000 clienti e ricevere un paio di telefonate, probabilmente stai bene. Se distribuisci una patch minore a 10 clienti e devi fare gli straordinari a causa di ciò, probabilmente qualcosa non va.

— Hazzit
fonte

3

"Quando si utilizza il controllo delle versioni semantico, è ancora necessario decidere quali modifiche sono considerate" maggiori "e quali" minori "." - No, non c'è; che è definito con precisione nelle specifiche. "Esistono vari motivi per annullare il numero di versione o per non modificarlo." - No, non ci sono; c'è precisamente un motivo per aumentare il numero maggiore (di cui si tratta questa domanda), ed è definito precisamente nelle specifiche.

— Jörg W Mittag,

1

@ JörgWMittag O sto leggendo male, o la specifica dice specificamente quando DEVI urtare i numeri di versione, ma non dice nulla su quando PUOI.

— Hazzit,

-4

Il consenso sul significato dei numeri di versione è in effetti major.minor.revision.buildnumber

Se major sale rapidamente, potrebbe essere solo lo sviluppatore che ha tutte queste nuove idee e lavora sodo.

Nel mondo degli affari, tuttavia, potrebbero esserci altri motivi per incrementare il numero di versione principale. Piace

Le vendite sono in calo, i clienti / utenti stanno aspettando il prossimo grande rilascio prima di eseguire l'aggiornamento.
Il contratto afferma che i clienti hanno diritto ad aggiornamenti minori. Il fornitore non può addebitarli per questi, quindi un piccolo miglioramento viene venduto come un importante aggiornamento del prodotto.
Il concorrente X è stato nel gioco un po 'più a lungo, quindi il suo numero di versione principale sembra essere superiore al tuo. Questo fa sembrare che tu sia in ritardo, devi "recuperare".

— Martin Maat
fonte

6

La domanda è etichettata con il versioning semantico , il PO menziona il versioning semantico nella domanda e ha ribadito nei commenti che stanno usando il versioning semantico. Le specifiche SemVer indicano chiaramente quando vengono incrementate le versioni principali. Nessuno dei tuoi "altri motivi" si applica.

— Jörg W Mittag,