[HN Gopher] Pragmatic Versioning - An Alternative to Semver
___________________________________________________________________
Pragmatic Versioning - An Alternative to Semver
Author : seveibar
Score : 15 points
Date : 2023-12-04 03:44 UTC (19 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| seveibar wrote:
| An early draft of an alternate system to semantic versioning
| (semver) that I think is more useful in practice for both package
| maintainers (who don't want to evaluate every change for meaning,
| and want to be able to maintain large releases) and package
| contributors (who want to know what the maintenance period is)
|
| Pragmatic versioning reflects more closely what many mature
| projects do in practice. Feedback welcome!
| bensecure wrote:
| It basically just says that version numbers are meaningless and
| purely marketing. "Pragmatic" yes, but in need of
| standardization, no. The project comes across almost as a
| satire, so its odd for you to treat it as serious here.
| dbingham wrote:
| Honestly, this is all too often how versions actually get
| used - that's what makes it feel like satire. But there's
| nothing wrong with admitting that the ideal of Semantic
| misses the mark, looking at real world usage, and saying
| "Okay, maybe we should formalize that in some way." I can see
| that being useful, especially if people are able to say "We
| use PragVersion rather than Semantic" to communicate the
| reality, rather than saying "We use Semantic" when they are,
| in fact, using Prag.
| catlover76 wrote:
| I am surprised more software libraries don't simply use date
| versioning. What is the reason?
| deathanatos wrote:
| It doesn't convey useful information like Semver versioning
| does.
|
| (Now, why things that _don 't_ do Semver don't just do DateVer
| in lieu of that... IDK, really. Marketing likes to take
| advantage of it? ...& then you get stuff like the OP here.)
| nonameiguess wrote:
| You've made it pretty hard for anything downstream to declare a
| dependency on a version range. They can depend on a date range,
| but it's not clear what basis there is for picking any
| particular upper bound other than "last known working version."
| mostlylurks wrote:
| With semantic versioning, it's easy to go back and provide a
| security update (for instance) for an earlier version of a
| library (which matters if the newer version is API compatible
| or has different dependencies or a different license or has
| stopped supporting the platform the user is on). If you try to
| do the same with date versioning, your versioning suddenly
| because very misleading and confusing.
| golergka wrote:
| Because software versioning is non-linear. A security patch to
| a previous LTS version can be newer than a new version of the
| software.
| travisjungroth wrote:
| Dates are one dimensional, monotonic, totally non-strictly
| ordered. There's no room for branching. Branching is necessary
| anytime you want to have multiple "latest"s. This is usually
| major releases with ongoing bugfixes and security updates but
| minimal breaking changes.
|
| What I've never seen, but seems useful, is to throw the date on
| the version number as the third or last number. The nice thing
| is you get the ordering back. Something like 4.3.20231204
| m4dc4pXXX wrote:
| Needs examples.
| simonw wrote:
| > In Semantic Versioning, there is no way to release or
| communicate a LTS/"long term support" version of a package. In
| Pragmatic Versioning, this is solved with a BIGRELEASE version,
| which has meaning that can be controlled by the package author.
|
| That doesn't make sense to me.
|
| With semantic versioning the way you communicate a LTS version of
| a package is you declare that in your documentation. Django
| (which doesn't fully use SemVer, but is still a good example
| here) does that on this page:
| https://www.djangoproject.com/download/#supported-versions
|
| "In Pragmatic Versioning, this is solved with a BIGRELEASE
| version, which has meaning that can be controlled by the package
| author" - that doesn't appear to address the need for LTS
| communication at all. It feels like the situation is exactly the
| same as SemVer: if you want to do LTS you have to represent that
| outside of the version number.
| natbennett wrote:
| "There's no way to..." is maybe imprecise phrasing but this is
| a real problem.
|
| Marketing departments really want to use that first number for
| Big Important Releases and _only_ Big Important Releases.
|
| I have seen products get their version incremented from 2.x.x
| 3.0.0 to indicate that an entirely different product (that
| could be deployed alongside the first but was otherwise
| unrelated) was being launched.
| herpdyderp wrote:
| Also
|
| > BIGRELEASE version, which has meaning that can be controlled
| by the package author
|
| So BIGRELEASE doesn't actually convey LTS at all. Meaning,
| Pragmatic Versioning does not solve LTS any more than Semver
| does.
| simonw wrote:
| "Democracy is the worst form of government, except all those
| other forms that have been tried from time to time." - attributed
| (but likely not accurately) to Winston Churchill
|
| Looks to me like Semantic Versioning is the worst form of
| versioning except for everything else we've tried.
| natbennett wrote:
| This is great. Especially for products that need long term
| support, which is basically not compatible with semantic
| versioning. (Since LTS versions occasionally must have security
| fixes that are also breaking changes backported.)
| baq wrote:
| Versions are a communication tool.
|
| There is no best tool for all jobs.
|
| Write down your communication objectives and pick a versioning
| scheme which fulfills them. Want to communicate api
| compatibility? Use server. Want to communicate a new version
| worth at least checking out? Bump that major version.
| herpdyderp wrote:
| This sounds similar to how TypeScript versions are named and it
| is a huge pain to me. Can I upgrade from 5.2.2 to 5.3.2 without
| everything breaking? Who knows. I thought I could, but I was
| wrong. Semver (when followed correctly, of course) would've
| conveyed this information instantly.
|
| I don't care about the branding, I just want my code to work.
| (Disclaimer: I am obviously not in marketing.)
| bombcar wrote:
| To be fair, Semver also falls apart relatively regularly, where
| a major version upgrade is easy and fine, but a minor upgrade
| trips you up.
|
| Even if an API stays exactly the same, something about what it
| returns could subtly change, so there's really no replacement
| for extensive testing.
___________________________________________________________________
(page generated 2023-12-04 23:00 UTC)