In un framework open source le API deprecate sono state rimosse durante la fase beta sulla strada verso una nuova versione principale. Ora gli utenti richiedono di ripristinare alcune API deprecate perché interrompono la compatibilità. Per me, beta sta per "Usa a proprio rischio".
Come già accennato, attualmente i tuoi utenti si lamentano di sulla strada verso una nuova versione principale .
Isn't it expected that due to a major version bump the API may change?
O non si apportano modifiche all'indietro incompatibili nell'API, o lo si farebbe in un bump di versione principale. Se non lo fai in un bump di versione principale, dove lo faresti? A meno che non lo facciate in un bump di versione minore, che è ovviamente ancora più improprio. Quindi, in pratica, non c'è nessun posto migliore per farlo a parte un bump della versione principale, vero?
Le modifiche alle API sono o non sono previste in una modifica di versione principale, a seconda del sistema di controllo delle versioni dell'API. Sembra che nel tuo caso lo sia. Questa è la tua decisione, anche se comune. A meno che tu non stia pianificando di apportare modifiche retroattive incompatibili.
Is it "uncommon" to change the API in a beta phase?
La fase beta , in base all'utilizzo specificato nel tuo post, può essere assunta come "anteprime di un candidato di rilascio" , e "non finalizzato" . In caso di modifiche incompatibili con le versioni precedenti, dovresti rilasciarle il prima possibile per dare più tempo agli utenti della tua API, ad esempio, per risolvere i problemi di compatibilità. Ovviamente, non lo farai nelle versioni prima dell'urto della versione a causa di ovvi motivi (hai già segnato @Deprecated nelle versioni precedenti! Perché le persone continuano a compilare il codice nonostante gli avvertimenti?). Dal momento che hai intenzione di apportare queste modifiche al candidato per il rilascio in ogni caso, perché lasciarle in seguito? Inoltre, tecnicamente le tue versioni beta sono già in versione major-bumped.
Questa domanda può anche essere intesa come le versioni beta delle modifiche betwteen della stessa versione. Finché si aggiungeranno queste modifiche al bump della versione principale, non si tratta di un problema. Dopotutto, durante la fase beta, le modifiche API possono essere considerate come "modifica non ancora completata".
Infine, ricorda sempre: ogni singola modifica rompe la compatibilità all'indietro.
xkcd: Workflow -- There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.
Per citare Version 2.0 semantico
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Quindi, se parli di una beta come la versione 0.x.x allora sì. Ad ogni modo, considerando la sezione 8
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.
e sezione 10
A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
Se stai parlando di una beta come versione instabile di una nuova versione, una modifica non retrocompatibile nell'API pubblica sarebbe "legale" se aumentassi la versione principale, ma non successivamente.
Credo che molti progetti utilizzino il versioning semantico o uno schema di versioning simile. Comunque, qualsiasi cosa detta vale solo per il versioning semantico. Se stai seguendo il tuo schema di versioning sei libero di fare tutto ciò che vuoi, ma se continui a infrangere le API pubbliche le persone che usano la tua libreria potrebbero essere frustrate e smetterla di usarlo, quindi dovresti considerare di mantenere tutte le modifiche in un ramo di sviluppo e solo rilascia una beta di una nuova versione se sei sicuro che non ci saranno altre modifiche nell'API pubblica.
Leggi altre domande sui tag versioning java beta
