Polygen e SemVer

[tajmone]

Ho visto che al codice ripultito in master hai assegnato le versione 1.0.6a.

Apro una parentesi riguardo SemVer, dato che si era discusso sulla possibilità di adottarne la notazione per le release di Polygen da questo repo in poi.

La versione 1.0.6a non è valida in SemVer 2.0, perché i tre segmenti devono essere solo numerici, o 0 o un numero qualsiasi non preceduto da zeri.

L'unico modo per creare una release successiva alla 1.0.6 è creare la 1.0.7 (o una maggiore). L'alternative è creare una prerelease della 1.0.7, per es 1.0.7-a o 1.0.7-rc1 (o qualsasi schema si voglia adottare pre le prerelease).

Il problema in questione è facilmente illustrabile tramite esempi pratici:

1.0.6   > 1.0.6-a
1.0.6-c > 1.0.6-b
1.0.6-c > 1.0.6-a
1.0.6-b > 1.0.6-a
1.0.6-b < 1.0.6-aa
1.0.6-a < 1.0.6-aa
1.0.6-12 > 1.0.6-9

In SemVer una prerlease è sempre inferiore ad una release (ossia una versione che non contiene il segmento di pre-release). L'ordine di precedenza tra le prerelease (in una stessa versione) ha delle regole un po' arzigogolate:

identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example:

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

Come accennavo, conviene sempre verificare la validità di una release SemVer tramite un validatore online:

http://jubianchi.github.io/semver-check/

che consente anche di verificare che la precedenza tra le varie prerelease sia corretta.

[alvisespano]

Ah sì scusa, me l'avevi anche detto ma me l'ero perso tra i milioni di robette in piedi :)
Allora la chiamo 1.0.6 e buona notte al secchio. Ma alla fine della festa è solamente la stringa nel file VERSION che cambia.

[tajmone]

Ovviamente non abbiamo alcun obbligo a seguire la SemVer 2.0 — e v1.0.6a rientra in uno schema noto e diffuso.

Git e GitHub non impongono restrizioni ai tag di release (puoi usare quello che vuoi, nei limiti dei soliti caratteri validi per un identificativo).

La scelta se adottare o meno SemVer 2.0 per Polygen dovrebbero prendere le mosse da altre considerazioni:

1. SemVer è uno standard comune nell'universo OCaml?
2. più importante: i package manager di OCaml (OPAM) adottano/impongono la SemVer?

Il punto 2 è il più cruciale a mio avviso. Tramite scorsa rapida sul sito di OPAM e nella sua documentazione non ho trovato da nessuna parte riferimenti a SemVer, e da questo Issue direi che non l'uso di SemVer non è poi così diffuso in OPAM:

Many people prefer semantic versioning (although perhaps fewer in the opam ecosystem than elsewhere).

• support for semver version constraint operator ocaml/opam#2976

Ho però trovato un modulo per gestire la SemVer su OPAM:

• https://opam.ocaml.org/packages/semver/

Sia quel che sia, credo concorderai che sarebbe comunque opportuno adottare uno schema di versione consistente nel tempo, di modo che i tag di release abbiano una loro coerenza.

[tajmone]

L'utilità di SemVer si rivela nell'uso di dipendenze esterne, dato che implementando dei constrain operators (come fanno Ruby e altri linguaggi) è possibile specificare l'inclusione di pacchetti entro un range specifico.

P.es:

~1.0
^1.2.3

ecc.

Ma visto che OPAM non impone la SemVer, e che non dispone dei costraint operators, non è che ci cambierebbe la vita usare SemVer.

Però SemVer è intuitiva, specie per le API, quindi direi che se è in vista la creazione di una libreria statica/dinamica di Polygen, l'adozione di SemVer è una buona scelta.

Alla fine, se ci limitiamo anche solo all'uso di x.y.z, senza prerelease o build metadata, si tratta di una semplice stringa facilmente intuibile e gestibile.