La versione principale veloce urtano una prova di design scadente?

16

Ho iniziato un lavoro come programmatore junior alcuni mesi fa. Il sistema su cui stiamo lavorando è stato in produzione per ~ 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.Y.Z. Dalla mia esperienza di lavoro con altri sistemi e librerie, non ricordo di aver visto un prodotto che batteva la versione principale in fretta. Esistono prodotti per anni in 1.X.Y, che continuano a ricevere funzioni e correzioni di errori.

Supponendo che il versioning semantico sia usato correttamente, questo indica che il sistema è mal progettato perché fa principali cambi di rottura quasi ogni quattro mesi?

    
posta user367035 11.03.2017 - 17:36
fonte

4 risposte

14

Assuming that the semantic versioning is used properly, does this indicate that the system is poorly designed since it makes major breaking changes almost every four months?

Non necessariamente.

Hai menzionato nei commenti che questa è un'API interna. Rompere un'API è brutto, perché infrangi il codice di tutti. Ma per un'API interna "tutti" sono solo "tu", e sei perfettamente in grado di coordinare tali cambiamenti API con te stesso, quindi il dolore che di solito è associato alle modifiche API è molto meno peggio.

Inoltre, la media potrebbe essere enormemente fuorviante: forse avevano 11 cambiamenti dell'API in fase di interruzione durante i primi due giorni di sviluppo iniziale e sono rimasti stabili da 4 anni? SemVer consente di apportare modifiche di rottura senza aumentare il numero maggiore se il numero maggiore è 0, ma non forza a. Forse hanno iniziato a usare SemVer dal giorno 0, anche durante le fasi di prototipazione / esplorazione?

    
risposta data 12.03.2017 - 12:08
fonte
1

Risposta breve

No

Risposta lunga

"A volte un numero è solo un numero"

Dimentica su "versioning semantico", "razionalità", "logica" in attuale mondo pazzo

Perché Chrome ingurgita numeri di versione così velocemente?

the "version" numbers are used as Milestones for the branch points, not Major Releases to wow the public the way other developers use them. And it's an ongoing development flow, with features ready or not ready, rather than an occasional event bringing together many new features to make a big event

    
risposta data 11.03.2017 - 18:15
fonte
-3

Quando si utilizza il controllo delle versioni semantico, resta comunque la decisione di stabilire quali modifiche siano considerate "maggiori" e quali siano "minori". Esistono vari motivi per eseguire il bump del numero di versione o per non eseguirne il bump.

I sistemi con le retrocompatibilità potrebbero finire con l'urlare il numero di versione principale con la maggior parte degli aggiornamenti, solo perché c'è una interruzione della compatibilità con le versioni precedenti in alcuni casi angolari più o meno esoterici. Gli stessi sistemi potrebbero rimanere fino a 1.x.y quasi indefinitamente, perché viene fatto un sacco di sforzi per la compatibilità a ritroso, cercando di non rompere mai alcun sistema dipendente. Entrambi gli approcci alla numerazione delle versioni potrebbero essere considerati "conservatori", ma entrambi potrebbero anche essere un segno di un profondo problema di fondo.

Altre volte, in realtà hai una pianificazione del rilascio (pensa ai CD di aggiornamento trimestrali inviati ai clienti), dove ha senso cambiare il numero di versione principale, in modo che invece di "Versione 3.4 / Ott 16 "dice solo" Versione 11.0 ". Al giorno d'oggi, sempre più software viene rilasciato a brevi intervalli, rendendo le pianificazioni di rilascio meno un motivo per attenersi a uno specifico sistema di controllo delle versioni. Ho visto questo nei grandi sistemi di magazzino che consentono all'IT interno solo un giorno di downtime su un quarto (di solito una domenica). Questo giorno è il giorno della distribuzione ed è contrassegnato ogni volta con una nuova versione principale.

Alcuni programmi hanno dipendenze esterne che sono della massima importanza, poiché l'utente dovrà aggiornarli entrambi allo stesso tempo. 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 importanti sono così importanti, perché alcuni dei tuoi utenti saranno "indietro" rispetto alla normale pianificazione degli aggiornamenti, dal momento che non sono stati aggiornati alla versione più recente di Word (o qualsiasi altra cosa su cui ti basi: SAP, Dynamics, ecc).

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

Alla fine, i numeri di versione dipendono da tanti fattori - spesso specifici per un dominio - che il numero da solo non ti dice nulla sullo stato della tua base di codice. È un approccio molto migliore da guardare quando, perché e come avvengono gli schieramenti, e con che facilità. Se riesci a implementare un importante aggiornamento a 10.000 clienti e fare un paio di telefonate, probabilmente stai bene. Se si distribuisce una patch minore a 10 clienti e si deve lavorare straordinariamente a causa di ciò, qualcosa è probabilmente sbagliato.

    
risposta data 12.03.2017 - 19:03
fonte
-4

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

Se il maggiore sale velocemente, potrebbe essere solo lo sviluppatore che ha tutte queste nuove idee e lavora davvero sodo.

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

  • Le vendite sono in calo, i clienti / gli utenti sono in attesa della prossima grande major release prima dell'aggiornamento.

  • Il contratto indica che i clienti hanno diritto a aggiornamenti minori. Il venditore non può caricarli per tali motivi, quindi alcuni miglioramenti minori vengono venduti come aggiornamento di un prodotto importante.

  • Il concorrente X è stato nel gioco un po 'più a lungo quindi il loro numero di versione principale sembra essere più alto del tuo. Questo fa sembrare che sei in ritardo, devi "recuperare".

risposta data 11.03.2017 - 22:26
fonte

Leggi altre domande sui tag