# A very, very, short review of versioning

Some highlights from how different comunities have tackled identifying versions of software artifacts. And, relatedly, resolving the quesiton of "should I replace v.x with v.y ?"

# Go Lang

## SCITT Artifact

go module, which is typically fetched as a collection of source files over the public internet and built locally

## Versioning style

Now mostly semver, with some escape hatches. And also an accomodation for the 'unversioned' special case of go modules from *prior* to the approach being standardised

* https://go.dev/ref/mod SCITT Artifact = go module
* https://go.dev/ref/mod#minimal-version-selection how the go community answer 'should I replace v.x with v.y'

# Python

## SCITT Artifact
* a directory on disk with special marker files
* a zip file with a file name matching some regex
* a file with a .whl extension
* I think there is a .exe installable form
* a .egg file
* a single file with a .py extension
* ... and so on. a history of almost 25 years.

## Versioning style

Now semver, but also community specific spin. They have a whole community working group dedicated to packaging. They have a great review of the history of versioning and packaging here:

https://www.pypa.io/en/latest/history/

In that history there is quite a lot of divergent opinion regarding 'should I replace v.x with v.y'

# Debian

I'm not so familiar with this but here is an 'above the fold' hit on google:

* https://unix.stackexchange.com/questions/96599/understanding-debian-dpkg-package-version-numbers for the packages comprising the distribution

## SCITT Artifact

Arguable, but the following would all find supporters:
* A distribution name, its not actually a file, archive or cd 'debian bookworm', it *has* variants arm64 etc
* A cd .iso file
* A repository eg, https://wiki.debian.org/DebianStable

I include debian as it surfaces the package vs collection issue. Both would sensibly make feeds

# Linux distributions in general

Check this out: https://distrowatch.com/dwres.php?resource=family-tree

Many nodes on that graph have there very own packagers, apt, rpm, apk, ...

And each of those packagers has re-spins and variants

## SCITT artifact

Same as for Debian

Then there are all the other communities

* npm https://dev.to/typescripttv/understanding-npm-versioning-3hn4
* cargo https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html

# Opinion

Many of those 'just use semver', but I don't believe they can be said to use semver in a mutualy consistent way. So either

a) permit each comminity a way to directly express their version information
b) define scitt semver and require all comminities, or consumers of sofware from those communities, understand how to translate from npm-semver, pypi-semver, go-semver -> scitt semver

Something that may be fertile ground is the idea that these comminities represent meaningful authorities for 'defacto' standards. Defacto standards are a fact of life, I count on them on a daily basis as a practitioner in the space. They are going to continue to evolve at pace.

A key problem for a developer consuming a mixture of sofware, that has origination spaning many of those communities, is simply "what is the authorative source of information blessed by this software comminity" ?

If a vendor is supplying rkvst-python sdk as a python artefact, what rules are they playing by when they publish an artifact with an updated version 'string' ?

As a consumer, possibly responsible for SOUP checking software, or otherwise making quality judgements, being able to identify the correct rule book is helpful.

Being required to only select sofware that has translated itself, from the natural rule book of its originating community, to the new scitt rule book, and then understand how the translations work, seems a pretty hard sell

And this is without considering CALVER. Or microsoft build numbers or, ...