Diciamo che c'è un pacchetto, foo . Foo è stato sviluppato principalmente in Python, fino alla versione 1.13.2 . In quel momento, lo sviluppatore principale decide che Go è molto più adatto all'attività. Crea un nuovo ramo e codifica un pacchetto in Go che ha le stesse funzionalità o anche alcuni miglioramenti a 1.13.2 della versione di Python.
Dopo il versioning semantico, è appropriato per lui fonderlo nello sviluppo, urtando la versione principale, come 2.0.0 ?
Da semver.org
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Quello che stai descrivendo sono i metadati di costruzione.
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
Dopo MAJOR.MINOR.PATCH-prerelease + BUILDMETADATA e poiché non hai menzionato alcun stato di prerelease:
1.13.2 + Vai
Se invece passasse alla versione 2.0.0, mi aspetterei che si verificasse un cambiamento irreversibile, il che significava che avrei dovuto riscrivere le mie cose per farlo funzionare a causa di incompatibili modifiche API. Se ciò non è vero, stai perdendo clienti senza una buona ragione.
Leggi altre domande sui tag version-control versioning semantic-versioning