Spiegazione
Innanzitutto vorrei definire brevemente come sto usando termini (potrei piegare il loro uso tipico un po ' ):
Quando parlo di cambiamenti semantici di rottura , mi riferisco a un cambiamento nel significato / comportamento di un'API pubblica. Potrebbe richiedere modifiche al codice del consumatore, ma non è immediatamente ovvio, poiché non è stato interrotto nulla. Le modifiche sono richieste solo perché le ipotesi fatte su precondizioni / comportamento non sono più valide.
Ciò è in contrasto con le modifiche alla rottura sintattica con cui mi riferisco alle modifiche apportate all'API pubblica che richiedono che il codice chiamante cambi il modo in cui chiama l'API. Questo tipo di cambio di rottura è ovvio poiché di solito si traduce in errori di compilazione che devono essere corretti.
Esempio
Diciamo che sto scrivendo un micro-ORM che ha dato un oggetto POCO, una connessione al database, e una query mapperà i risultati nell'oggetto per te. L'API pubblica, è abbastanza semplice:
Query<T>(connection As IDbConnection, sql As String)
È molto improbabile che abbia un cambiamento sintattico nel modo in cui interagisci con questo strumento. Tuttavia, dato che c'è un sacco di comportamenti legati a questa semplice affermazione, sono molto probabile che abbia dei cambiamenti semantici.
Domanda
Poiché non c'è alcuna modifica della sintassi, come posso comunicare efficacemente ai consumatori della mia API che c'è stata una modifica semantica? Dovrei sempre raggruppare i cambiamenti semantici in cambiamenti sintetici quindi non c'è dubbio che qualcosa è cambiato?
Se il versioning semantico comprende modifiche sia semantiche che sintattiche, allora c'è molto da fare per risolvere il problema. Ma sarebbe ancora possibile per gli sviluppatori costruire contro una versione più recente, non notare alcun errore di compilazione, supporre che le cose andranno bene (dal momento che non hanno letto i documenti) e introdurre bug dovuti a cambiamenti semantici nella mia API.