Calver vs Semver

[dijonkitchen]

Wondering if Calendar versioning might be better than Semantic versioning for tea.

https://sedimental.org/designing_a_version.html
https://calver.org/
https://semver.org/

[mxcl]

When a project depends on another project it does so typically by specifying the API version it requires via the major version component of the semantic version. When a project breaks its API version it must bump its major version. If it fails to do this the tea DAO will slash its token.

As much as I really like calendar versioning, it would not be possible (as far as I can see) for a project to specify this API contract and we would need another mechanism.

[dijonkitchen]

Semver is great, but maybe the question is whether we can really trust it to be right all the time? Could some of the teaconomics be used to keep this in line and/or utilize it for versioning itself? E.g., slash tea when there is a breaking change without a major version or auto-increment major when enough people report there to be some breaking change?

[mxcl]

We intend to slash packages that break semantic versioning. The entire open source graph can be disrupted if authors break APIs so we think it is reasonable such packages be penalized.

[mxcl]

HOWEVER! a calendar version is a valid semantic version. We could encourage apps (ie. packages that are not dependents) to adopt this versioning.

It kinda has a retro feel even, like Windows 95.

And carries some useful info too, letting the user implicitly know how old their installation is.

[dijonkitchen]

Yeah, I was thinking along the line of incentives for maintainers to not have breaking changes for major version bumps but also encouraging them to keep things up to date. Similar in vision to tea I think.

[serapath]

[jhheider]

Correct. Any (rational) version system will translate to a canonical determinator (one or more hashes, as you say) so that a version is forever verifiable.