Quanto attendere prima di eliminare un metodo obsoleto? [chiuso]

Sto mantenendo un'API pubblica e devo deprecare un metodo.

Esiste una regola generale su quanti mesi / anni / versioni prima dell'eliminazione dovrei deprecare un metodo?

Come minimo, dovresti mantenere i metodi obsoleti in una versione prima di rimuoverli, il che sembra ovvio quando lo scrivo. Non credo che ci sia un tempo massimo, ma se non li rimuovi davvero, la deprecazione diventa un po 'inutile.

Le versioni principali della versione sono un buon momento per rimuovere i metodi obsoleti. Le versioni minori in genere non devono contenere modifiche di rottura. Come cHao ha notato nei commenti, la deprecazione non implica necessariamente che ci sarà un'eventuale rimozione, quindi se prevedi di rimuovere le cose dopo la deprecazione, dovresti esplicitamente notare che e fornire alcune indicazioni sulla sequenza temporale.

Ciò dipende esclusivamente dal tipo di stabilità che hai garantito ai tuoi utenti e dalla quantità di dolore che desideri causare ai tuoi utenti.

Idealmente, l'API utilizza semver in modo tale che qualsiasi modifica errata causi l'incremento del numero di versione principale. In pratica, è desiderabile farlo quasi mai. Se la tua API è installata tramite un gestore pacchetti, potresti voler creare un nuovo nome pacchetto dopo una modifica in modo che un semplice aggiornamento non causi conflitti (ad es. myapi2 v2.123.4Vs myapi3 v3.2.1). Ciò potrebbe non essere necessario se il gestore pacchetti supporta dipendenze di versione più strette (ad esempio una specifica di dipendenza come ~v2.120quella non include v3.*), ma nomi di pacchetti diversi hanno il vantaggio che versioni incompatibili possono essere utilizzate fianco a fianco molto facilmente. Anche quando si utilizza semver, può essere sensato avere un periodo di ammortamento.

Semver non è sempre applicabile. Quindi è più importante comunicare una chiara politica di stabilità. Per esempio:

• Le funzionalità sperimentali possono essere rimosse senza preavviso.
• Le funzionalità possono essere rimosse per motivi di sicurezza in qualsiasi momento.
• Altre funzionalità verranno rimosse
  • ... dopo essere stato deprecato in una versione rilasciata
  • ... dove quella versione ha almeno tre mesi
  • ... e sarà segnato da un bernoccolo nella versione principale.

Tali politiche funzionano particolarmente bene quando si hanno rilasci regolari in modo che vi sia un chiaro periodo di ammortamento, ad esempio un anno.

Oltre a contrassegnare le parti dell'API come deprecate, è necessario rendere ampiamente nota la deprecazione. Per esempio:

• Inserisci una sezione nel tuo log delle modifiche su direzioni e ammortamenti futuri.
• Trasmetti l'intenzione di deprecarti prima di eseguire l'ammortamento e ascolta la community per vedere se ci sono obiezioni sostanziali.
• Comunicare quali benefici arriveranno da questi cambiamenti. A seconda della base di utenti, newsletter, presentazioni, post di blog o comunicati stampa potrebbero essere i media appropriati. Girando “stiamo creando una nuova fantastica funzionalità! (che richiede la rimozione di questa vecchia funzionalità ampiamente utilizzata) "è un po 'meno frustrante rispetto alla rimozione di una funzionalità senza contesto.

Per quanto riguarda l'esatto periodo di ammortamento da scegliere, per prima cosa controlla se devi onorare eventuali contratti di supporto con i tuoi utenti. Tali contratti potrebbero richiedere il mantenimento della compatibilità per un certo periodo. In caso contrario, considerare qualsiasi impatto a valle. Prova a cambiare meno rapidamente degli utenti a valle in modo che possano attraversare un ciclo di ammortamento autonomo. Gli utenti a valle impiegheranno un po 'di tempo per adattarsi alle modifiche, quindi non dovresti mai avere un periodo di ammortamento inferiore a un mese.

Idealmente, dovresti aspettare fino a quando nessuno sta più usando il metodo deprecato. Considerando che stai utilizzando un'API pubblica, è facile da tenere traccia, ma potresti finire per aspettare molto tempo.

nel 2015 Google ha riscontrato un problema simile con l'API stlport sul proprio sistema operativo Android. Lo avevano deprecato e volevano rimuoverlo, ma tonnellate di app lo stavano ancora usando. Hanno trovato una soluzione intelligente:

In sostanza, hanno aggiunto uno sleep di 8 secondi () durante l'avvio di qualsiasi app che utilizzava ancora l'API con un messaggio di log appropriato per gli sviluppatori. Un mese dopo, lo raddoppiarono a 16 secondi. poi un altro mese dopo, potevano tranquillamente rimuovere l'interfaccia API perché non era rimasto nessuno che la usasse.

Questo può essere un modo molto efficace per farlo. L'unico vero problema è se la tua API è molto vecchia e ha attivamente utilizzato i consumatori che non sono più attivamente supportati. Sfortunatamente, probabilmente non sarai in grado di riparare da solo tali consumatori, ma a quel punto non puoi davvero fare molto di più che eliminare il metodo e rompere il consumatore.

Il tempo minimo per fornire metodi obsoleti dipende dai cicli di sviluppo dei programmi che utilizzano l'API. Come figura da ballpark, 1 anno dovrebbe essere sufficiente.

Per quanto riguarda il tempo massimo prima che tu debba rimuovere i metodi obsoleti, direi che non esiste nulla del genere. Indipendentemente dal tempo di attesa, la rimozione di un metodo obsoleto interromperà sempre qualcosa. Alcuni programmi che utilizzano l'API obsoleta non vengono mantenuti attivamente e l'interruzione della compatibilità comporterà la fine della vita di tali programmi.

Ti suggerisco di rimuovere i metodi obsoleti quando ottieni qualcosa dalla rimozione :

• viene rilevato un bug che interessa specificamente i metodi obsoleti
• stai per riformattare il codice e mantenere metodi deprecati richiederebbe uno sforzo notevole
• stai ottimizzando la struttura interna della tua libreria e i metodi obsoleti non si adattano più.

Rimuovere i metodi obsoleti solo perché sono stati deprecati per X mesi / anni o perché stai rilasciando una nuova versione equivale a danneggiare arbitrariamente la compatibilità senza una buona ragione.

Per prima cosa dovresti considerare se vuoi essere deprecato o obsoleto.

Deprecato dovrebbe essere usato per metodi che sono in qualche modo dannosi: sicurezza, prestazioni, risultati errati. Vuoi sbarazzartene relativamente velocemente, non più di 2 versioni principali e passate al 3 °. Per problemi abbastanza significativi, deprecati possono essere eliminati nella prossima versione secondaria.

Obsoleto è per cose che sono meno utili per qualche motivo, ad esempio restituisce meno informazioni o non funziona altrettanto bene, non include tante opzioni e così via. Questi possono rimanere in giro indefinitamente, ma dovrebbero almeno essere presenti nella prossima versione principale.

La risposta dipende dal tipo di servizio che offri ai tuoi clienti.

A un estremo dell'estremo, ci sono errori in Windows.h dell'era Win 3.1 che si propagarono per due decenni perché Microsoft credeva fortemente nella compatibilità con le versioni precedenti.

All'altra estremità dello spettro, molte app Web rimuovono le funzionalità senza nemmeno fornire un avviso di deprecazione.

Quanto spesso i tuoi clienti pagano per il tuo software sono importanti, così come la loro linea di lavoro. I ricercatori sono in genere più disposti ad accettare la deprecazione come parte della marcia del progresso rispetto, per esempio, ai banchieri o alla FAA.

Ho lavorato per un'azienda che sviluppa software per uso interno. Ho supportato molti gruppi nel corso degli anni. Un gruppo aveva una mentalità "non rimuovere mai alcuna caratteristica". Avevano bisogno della capacità di tornare ai file 5-10 anni fa e fare analisi su di essi su scale temporali troppo velocemente per indurre gli sviluppatori a ripristinare le funzionalità. L'atteggiamento di un gruppo era "assicurarsi che tutte le deprecazioni siano nelle note della patch, quindi noi li troverò più tardi. " Nel mezzo, avevamo un gruppo la cui regola era "Le funzionalità devono essere deprecate per almeno 1 versione con un avviso stampato se vengono utilizzate prima di rimuoverle." Quel gruppo aveva una suite di test che copriva le funzionalità di cui aveva bisogno. Ogni volta che abbiamo rilasciato una nuova versione, hanno rapidamente eseguito la loro suite di test contro di essa per vedere se una qualsiasi delle deprecazioni ha causato loro problemi.

Sto mantenendo un'API pubblica e devo deprecare un metodo.

Perché hai bisogno di fare questo? È perché c'è un nuovo modo brillante di fare le cose, quindi il vecchio metodo è ora scoraggiato, ma funziona ancora bene? O il vecchio metodo deve effettivamente andare perché le cose sono sostanzialmente cambiate?

• Se il vecchio metodo non sta causando problemi reali e può rimanere in sospeso, allora potrebbe anche. Se non è rotto, non aggiustarlo. Hai davvero bisogno di rimuoverlo? Forse contrassegnarlo come obsoleto e includere nella documentazione una nota secondo cui un altro metodo potrebbe essere più efficiente, o altro, ma probabilmente va bene lasciarlo al suo posto.

• Se il vecchio metodo ha davvero bisogno di andare, perché ti sta causando mal di testa da manutenzione o perché semplicemente non ha più senso a causa di altre modifiche, quindi monitora il suo utilizzo e comunica chiaramente la deprecazione ai clienti. Dagli una data chiara dopo la quale il metodo verrà rimosso. (Idealmente, non rimuoverlo immediatamente in questa data: attendere fino a quando nessuno lo sta ancora utilizzando prima di rimuoverlo. Potrebbe essere necessario andare prima, se sta davvero causando problemi, ma almeno attendere che l'utilizzo rilasci piccolo.)

• Se il vecchio metodo sta causando problemi di sicurezza, potrebbe essere necessario spostarsi più rapidamente di quello, eventualmente rimuovendolo senza preavviso, ma è necessario documentare questa modifica in un punto molto visibile e restituire anche i messaggi sensibili ai client che tentano di utilizzare il vecchio metodo.

(I secondi due punti elenco sono ben coperti in altre risposte, ma penso che il primo sia nuovo.)

Per un progetto pubblico, rimuovilo solo se e solo se necessario.

Quando esegui una rimozione dell'API non necessaria, stai costando soldi per aziende e appaltatori in modo tale che non puoi nemmeno calcolare a causa di costose spese.

Vuoi che aziende e programmatori indipendenti smettano di usare il tuo progetto? Rompi le loro cose abbastanza volte quando non sei essenziale e sarai in quella barca in pochissimo tempo.

deprecation != eventual_removal. Se un'API è pericolosa, la rimuovi. Se è solo vecchio, lasciarlo e documentare la sua sostituzione.