Oh I read the most important thing, the original page.
>TrunkVer is a SemVer-compatible versioning scheme for continuously-delivered, trunk-based applications and systems that don't follow a release scheme.
It's not compatible with SemVer. I've explained why it isn't compatible in any sense multiple times now in various comments, probably most of them in reply to you.
>Repeat after me: the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions.
Just because it fits doesn't mean it's "compatible". If you apply this TrunkVer scheme to a library, continuously deployed or not, the result is a disaster.
>I really don’t get what your obsession is with compatibility and package managers.
>the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions.
A "deployment system" that you need to integrate with is most commonly a package manager.
>Repeat after me: the use case that fits this involves the need a versioning scheme that’s better than a meaningless incrementing integer
This may be more informative than an incrementing integer, but it is still not compatible with SemVer as the original page claims, and it is neglects many important considerations like variance between the build date, code version, and authorship date.
If you're going to reply to me again about this I suggest that you follow your own advice, because I've given fairly definitive objections to this scheme already:
>Stop and actually read what people are telling you before replying.
> If you apply this TrunkVer scheme to a library, continuously deployed or not, the result is a disaster.
Cool, except those are not systems or an applications are they?
> A "deployment system" that you need to integrate with is most commonly a package manager.
Completely incorrect for systems and applications.
> If you're going to reply to me again about this I suggest that you follow your own advice, because I've given fairly definitive objections to this scheme already
You did it again. You didn’t read.
> Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints.
My mentioning the specific case of a library does not invalidate anything else I said as it applies to applications. As I mentioned in another comment, applications (and "systems" which are often just an application bundled in a docker container or something) involve data, and SemVer communicates which versions are compatible with which.
>> A "deployment system" that you need to integrate with is most commonly a package manager.
>Completely incorrect for systems and applications.
I'm not wrong, but keep hitting the copium bro.
>Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints.
As I said, nearly everyone has compatibility concerns, or can develop them at any time. This is a short-sighted scheme. I can't deny that it "works" in some sense for a small number of people who are willing to make bad assumptions like that. But I cannot in good faith recommend it to anyone.
I'm not sure what you mean but if you're asking for a solution then SemVer is better than this in most cases. It has none of the issues I mentioned caused by TrunkVer.
>Do you think the deployment version is an appropriate format to convey compatibility in a system of that size and complexity? = I do not
OK I wonder how GitHub does self-hosting, migrations, etc. I assume they have bespoke upgrade scripts to migrate, and you might have to run them in a sequence. That doesn't mean SemVer is inappropriate. It just isn't going to help much.
>- Do you think it is deployed via a package manager like NPM or Bundle? = I do not
Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer. The only real argument against that is that you can't tell the API version supported from an unrelated SemVer number.
It’s not supposed to be informative. It’s not supposed to be parsed. It’s a version identifier. The date is much better than a commit hash or an opaque number for this.
Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not.
If it’s not compatible, it’s a new version.
Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you.
> That doesn't mean SemVer is inappropriate. It just isn't going to help much.
Irrelevant.
> Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer
>Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not.
Not true. You can be compatible with all APIs, adding no new features; you can add new features; and you can break existing features. These are the levels that SemVer can communicate. This makes as much sense for a web API as a binary library.
>Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you.
What all 3 of them? A vast majority of people prefer SemVer even if they detest the work that it generates. It's like a form of documentation.
Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints.
Repeat after me: the use case that fits this involves the need a versioning scheme that’s better than a meaningless incrementing integer”
Repeat after me: the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions.
Repeat after me: I want a semver compatible versioning scheme.