Quanto tempo è necessario attendere prima di eliminare un metodo deprecato? [chiuso]

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

Le versioni principali delle versioni sono un buon momento per rimuovere i metodi deprecati. Solitamente le versioni minori non contengono 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 tenerne conto esplicitamente e fornire indicazioni sulla timeline.

Dipende unicamente dal tipo di stabilità che garantisci ai tuoi utenti e da quanto dolore vuoi causare ai tuoi utenti.

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

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

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

Tali politiche funzionano particolarmente bene quando si hanno rilasci regolari in modo che ci sia un chiaro periodo di deprecazione, ad es. un anno.

Oltre a contrassegnare qualsiasi parte dell'API come deprecata, dovresti rendere ampiamente noto il deprecation. Ad esempio:

• Avere una sezione nel tuo log delle modifiche sulle indicazioni future e sulle deprecazioni.
• Trasmetti la tua intenzione di deprecare prima di eseguire la deprecazione e ascolta la community per vedere se ci sono obiezioni sostanziali.
• Comunicare quali benefici deriveranno da questi cambiamenti. A seconda della base di utenti, newsletter, presentazioni, post di blog o comunicati stampa potrebbero essere supporti appropriati. Fare un giro "stiamo creando una nuova fantastica funzionalità! (che richiede la rimozione di questa vecchia funzione ampiamente utilizzata) "è un po 'meno frustrante della rimozione di una funzionalità senza contesto.

Per quanto riguarda il periodo esatto di deprecazione da scegliere, per prima cosa guarda se devi onorare eventuali contratti di supporto con i tuoi utenti. Tali contratti potrebbero richiedere di mantenere la compatibilità per un certo periodo. In caso contrario, considerare eventuali impatti a valle. Prova a cambiare meno rapidamente rispetto agli utenti a valle in modo che possano passare attraverso un ciclo di deprecazione. Gli utenti a valle impiegheranno un po 'di tempo per adattarsi alle tue modifiche, quindi non dovresti mai avere un periodo di deprecazione più breve di un mese.

Idealmente, vorresti aspettare fino a quando nessuno usa più il metodo deprecato. Considerando che stai utilizzando un'API pubblica, è facile da tracciare, ma potresti finire per aspettare molto a lungo.

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

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

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

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

Per quanto riguarda il tempo massimo prima di dover rimuovere i metodi deprecati, direi che non esiste una cosa del genere. Indipendentemente dal tempo che aspetti, la rimozione di un metodo deprecato causerà sempre la rottura di qualcosa. Alcuni programmi che utilizzano l'API deprecata non vengono mantenuti attivamente e la rottura della compatibilità significherà la fine della vita di tali programmi.

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

• viene rilevato un bug che interessa in modo specifico i metodi deprecati
• stai per ridefinire il codice e il mantenimento dei metodi deprecati richiederebbe uno sforzo significativo
• stai ottimizzando la struttura interna della tua libreria e i metodi deprecati non si adattano più.

Rimuovere i metodi deprecati 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.

Innanzitutto dovresti considerare se vuoi deprecato o obsoleto.

Obsoleto dovrebbe essere usato per metodi che sono in qualche modo dannosi: sicurezza, prestazioni, risultati errati. Volete sbarazzarvi di loro in tempi relativamente brevi, non più di 2 versioni principali e passati al 3 °. Per problemi abbastanza significativi, deprecato può essere eliminato nella prossima versione minore.

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 aggirarsi indefinitamente, ma dovrebbero essere presenti almeno nella prossima versione principale.

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

Da un'estremità all'estremo, ci sono errori in Windows.h dell'era di Win 3.1 propagati per due decenni perché Microsoft credeva strongmente nella retrocompatibilità.

Dall'altra parte dello spettro, molte web-app rimuovono funzionalità senza nemmeno fornire un avviso di deprecazione.

Spesso i tuoi clienti pagano per il tuo software, così come la loro linea di lavoro. Gli scienziati ricercatori sono in genere più disposti ad accettare la deprecazione come parte della marcia del progresso rispetto, ad 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à da "non rimuovere mai nessuna caratteristica". Avevano bisogno della possibilità di tornare ai file 5-10 anni fa e fare analisi su di essi in tempi troppo brevi per convincere gli sviluppatori a reinserire le funzionalità. L'atteggiamento di un gruppo era "assicurati che tutte le svalutazioni siano nelle note delle patch, quindi 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 avevano bisogno. Ogni volta che rilasciavamo una nuova versione, eseguivano rapidamente la loro suite di test contro di essa per vedere se una delle deprecazioni dava loro dei problemi.

I am maintaining a public API and have to deprecate a method.

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 in realtà ha bisogno di andare perché le cose sono fondamentalmente cambiate?

• Se il vecchio metodo non causa problemi effettivi e può essere attivo in giro, allora potrebbe anche Se non è rotto, non aggiustarlo. Lo fai davvero bisogno di rimuoverlo? Forse contrassegnalo come obsoleto e includi a nota nella documentazione che un altro metodo potrebbe essere più efficiente, o qualsiasi altra cosa, ma probabilmente è meglio lasciarlo al suo posto.

• Se il vecchio metodo ha davvero bisogno di andare, perché ti sta causando mal di testa di manutenzione, o perché semplicemente non ha più senso a causa di altre modifiche, quindi monitorare il suo utilizzo e comunicare il deprecazione chiara ai clienti. Dai loro una data chiara dopo la quale il metodo verrà rimosso. (Idealmente, in realtà non rimuoverlo immediatamente in questa data: attendi fino a quando nessuno lo sta ancora usando prima in realtà rimuovendolo. Potrebbe essere necessario andare prima, se è davvero così causando problemi, ma almeno attendi che l'utilizzo scenda un po '.)

• Se il vecchio metodo causa problemi di sicurezza, potrebbe essere necessario spostarsi più veloce di quello, forse anche rimuovendolo senza preavviso, ma tu dovrebbe documentare questo cambiamento da qualche parte molto visibile, e anche restituire 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 la rimozione non necessaria dell'API, stai pagando soldi per aziende e appaltatori in modo tale che non puoi nemmeno calcolare a causa di dispendiosi costi.

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

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