Il semere ora è uno standard? [chiuso]

2

C'è qualche motivo per un nuovo progetto pubblico in fase di avvio, se data la scelta (ad esempio, non è vincolata dalla loro società), userebbe qualcosa di diverso da Semver ? Esistono metodologie concorrenti, ad esempio Semver non è ancora stato ampiamente accettato?

Questa domanda sorge perché un pacchetto molto noto che uso aggiornato dalla 3.2 alla 3.3. Ho aggiornato ciecamente, pensando che questo potesse solo aggiungere nuove API, non rompere le vecchie API. E con mia sorpresa, 3.3 ha cancellato alcune API deprecate. Controllando il loro controllo delle versioni, non ha specificato quale "sistema" usano.

Quindi, dovremmo assumere che Semver è l'impostazione predefinita per [la maggior parte / tutti] progetti Github?

Modifica: semver.org

Modifica2: Penso che questo dibattito dipenda molto dal fatto che il software sia una libreria o una applicazione finale (l'utente è seduto di fronte ad essa che interagisce con esso). La mia intenzione originale era discutere il primo. Cioè, se il codice può essere una dipendenza in altro codice. Le librerie non semere rendono molto difficile sapere se è sicuro scaricare una versione più recente della libreria e dipendere da essa. Al contrario, non mi importa quale sia la versione di Firefox perché non la utilizzi come libreria, la stai usando come applicazione finale.

    
posta Tommy 14.04.2016 - 04:28
fonte

1 risposta

4

Il versioning semantico non è, AFAIK, uno standard ufficiale (secondo alcune organizzazioni come ISO). Ma sono così tanti che non possiamo essere sicuri (e certamente non conosco la maggior parte degli standard ISO).

E alcuni software non lo usano. Ad esempio, Frama-C sta rilasciando versioni che prendono il nome da un elemento chimico (ad esempio il berillio, ma il magnesio è stato rilasciato a gennaio 2016). / p>

Alcuni software hanno cambiato il loro schema di gestione delle versioni durante la loro vita. Un esempio notevole include GCC (e probabilmente anche il kernel di Linux): GCC usato per il numero 4.1, 4.2, .... per la versione significativa modifiche (con patchlevel come 4.1.2 o 4.1.3 per piccole correzioni di bug), ma ora stanno usando i numeri di versione come 5 o 6 (con 5.3 come patchlevel).

Alcune librerie software non hanno sempre alcun numero di versione, ad es. libonion (una libreria server HTTP per C & C ++, su github ; ma ha alcuni git-version-gen script).

(forse ho sbagliato, e libonion sta forse ottenendo informazioni e API di versione)

Il linker Linux fornisce il controllo delle versioni dei simboli. Vedi questo .

Alcune librerie C-callable forniscono simboli di preprocessore che guidano l'API implementata. GCCJIT utilizza "tag simbolo" come LIBGCCJIT_ABI_2 . Vedi anche feature_test_macros (7) & autoconf su Linux.

La libreria glib (in GTK) fornisce un'interessante API di informazioni sulla versione che potrebbe essere stimolante.

GCC & Clang ha l'attributo __attribute__((deprecated)) funzione per contrassegnare le funzioni che sono deprecate. C ++ 14 specifica l'attributo [[deprecated]] . Se si pubblica una libreria con una comunità di utenti significativa, probabilmente in alcune versioni si renderanno alcune funzioni deprecate e rimuoverle interamente solo in alcune versioni future. Si noti che nello standard C, la famigerata funzione è stata rimossa molti anni dopo essere stata annunciata come deprecata.

    
risposta data 14.04.2016 - 07:15
fonte

Leggi altre domande sui tag