Che cosa significa retrocompatibile significa se ci sono modifiche al cambiamento

1

Ho notato qualcosa di strano in alcuni progetti open source che usano la versione semantica. In React 15, il team React è passato a semiver . Allo stesso modo, il team di Angular è passato al semester in Angular 2.0.0.

Semver dichiara che un bump di versione maggiore avverrà "quando si apportano modifiche API incompatibili" . In React 16 e Angular 4 si verificano cambiamenti di rottura ma ho notato che entrambi i progetti hanno reso dichiarazioni come " sarà retrocompatibile, anche se, come per tutti gli aggiornamenti principali, ci saranno alcune piccole modifiche ". Lo noto con più di questi due progetti.

Sembra strano dire che è retrocompatibile tranne per le parti che non sono retrocompatibili. Perché un progetto dovrebbe scegliere di fare una dichiarazione così ridondante? Questo mi porta a chiedermi se esistono definizioni multiple per la retrocompatibilità di cui non sono a conoscenza (e che Semver non riconosce).

    
posta Lan 19.04.2017 - 18:13
fonte

3 risposte

4

Sembra che intendano solo "principalmente retrocompatibili".

La definizione di "retrocompatibile" praticamente è "non distruggere roba". Ma se ci sono alcune piccole modifiche alle cose usate raramente, che interessano solo una piccolissima porzione di utenti, potrebbe comunque essere accurato descrivere una nuova versione come totalmente compatibile con le versioni precedenti.

    
risposta data 19.04.2017 - 18:19
fonte
4

Ci sono un paio di cose che rendono la retrocompatibilità non banale.

In primo luogo, un vincolo che viene spesso utilizzato è che il tuo codice verrà compilato senza modifiche in una modifica compatibile con le versioni precedenti mentre in una modifica non retrocompatibile potrebbe richiedere modifiche al codice per la compilazione del codice rispetto alla nuova versione. Ovviamente, questo vincolo non è utile per JavaScript.

Questo porta all'idea generale, ovvero che il pubblico "contratto" del codice non cambia. I tipi sono una formalizzazione di un'approssimazione del contratto pubblico. Una suite di test è un'altra formalizzazione di un'approssimazione del contratto pubblico. Cioè, in una modifica compatibile con le versioni precedenti, tutti i test nella vecchia suite di test dovrebbero ancora passare. Sfortunatamente, ciò che fa parte del contratto pubblico non è quasi mai specificato in modo completo e spesso non è nemmeno completamente specificato in alcun modo. Il contratto pubblico è ciò che gli sviluppatori della biblioteca si impegnano a mantenere e l'unica cosa su cui puoi fare affidamento come consumatore, ma, soprattutto in un linguaggio come JavaScript, ci sono miriadi di dettagli che sono anche visibili che non fanno parte del pubblico contratto e quindi non può essere invocato. Ovviamente, questo non impedisce alle persone di affidarsi a loro.

Infine, c'è il caso imbarazzante in cui una biblioteca non rispetta il proprio contratto pubblico, cioè è buggy. In questo caso, i consumatori sono ovviamente costretti a fare affidamento sul comportamento effettivo della biblioteca e non sul suo comportamento previsto. Risolvere il problema, portando la biblioteca più in linea con il suo contratto pubblico, interromperà questi consumatori. Evitarlo si chiama mantenimento di compatibilità dei bug ed è un incubo che la maggior parte degli sviluppatori vuole evitare. Direi che il "consenso non espresso" è che i bug possono essere risolti senza preavviso.

In definitiva, è difficile apportare modifiche significative a una base di codice (a differenza di un'aggiunta pura), specialmente in un linguaggio come JavaScript, che non produce differenze osservabili a livello di codice. Ciò che serve come indicazione (parziale, informale) del contratto pubblico lascia di solito poco chiaro quale comportamento sia garantito in vari casi angolari. Anche data una specifica completa, di solito è proibitivamente costoso verificare effettivamente che il codice lo soddisfi. Quindi, alla fine della giornata, ciò che costituisce "retrocompatibile" di solito non è delineato nettamente, e anche se fosse (in senso significativo) sarebbe probabilmente troppo costoso per verificarlo realmente.

Quindi, sì, gli sviluppatori sperano che il cambiamento sia "retrocompatibile", proprio come sperano che il codice si comporti come è specificato nominalmente, ma tutti sono stati intorno al blocco abbastanza volte per sapere che tali speranze sono infondate.

    
risposta data 20.04.2017 - 00:16
fonte
0

Per me, se il codice è retrocompatibile vuol dire che, gli sviluppatori hanno fatto tutti i tentativi (i bug sono a volte un pericolo) per assicurarsi che passare da una versione all'altra sia facile e non richieda una modifica del codice.

Tuttavia, quando menzionano la rottura delle modifiche, questo di solito significa che le modifiche che è necessario apportare dovrebbero essere documentate e questa documentazione dovrebbe essere disponibile, quindi le modifiche che è necessario apportare sono note e possono essere spiegate.

La conoscenza delle modifiche alla rottura è molto meglio che succhiarla e vedere.

    
risposta data 21.04.2017 - 22:44
fonte

Leggi altre domande sui tag