Clojurians Log v2

https://github.com/dask/community/issues/100#issuecomment-704531301

https://jacobtomlinson.dev/posts/2023/sometimes-i-regret-using-calver/

> In my opinion, CalVer signals to your community that anything could happen at any time and that you have no interest in the effect that has on your users. Well, quite the opposite. I stopped using semver because I don't belive libraries should intentionally introduce breaking changes at all. Semver is just a way of communicating when you're breaking people. The difference between minor and patch has always felt arbitrary to me. In a project that takes backwards compatible seriously, a higher version number should indicate a more mature, stable and possibly more feature rich version.

Absolutely incredible stuff. I went into that talk a big fan of semantic versioning, came out completely disillusioned. Never used it since. I wish more people had this mindset.

Yeah. It adds relationship to what is so often disconnected and insular.

So then what are the version numbers even for? Even Clojure has three version segments

Does this imply that Clojure isn't semver'd?

Not exactly sure, but my impression is that Clojure is more or less semver, but you'll never see a 2.x. Most other libs have a version number that includes a number that increases for every release, and one that indicates the number of commits, which gives you some idea of the relative diff between two commits.

Oh that's interesting

Personally I just use dates as versions on all my libraries, e.g. 2023.09.04.

Ah, calver eh

😂

Right

If we abandon the idea of semver and promise never to break anything, then the only real constraint on the number is that it increases

Yep

It's then up to the developer to decide what that increase means. So... dates or commit counts or what-have-you

Why not just a single number then?

Version 1! Version 2!

It means "new version" 😅 can still have a changelog

Well, maven makes some assumptions about version numbers. Not sure if it's necessary to use multiple parts.

Ah

But you could use a single number. Even though it's not semver you could still communicate something with the number though.

Like the number of commits, which can give a quick impression of the amount of change/additions

I guess it's also a little bit of optics to it. People have expectations.

Without semver then there's no difference between the major and minor either

No

Honestly calver is tempting

I like it 😊

> I went into that talk a big fan of semantic versioning, came out completely disillusioned. My interest is piqued 🤔

The continuity is everything. It’s relationship. It makes coding a function of relationship instead of relationship a function of coding.

Can we use “semantic versioning”? Sure — we just have to define what it means. “We” here means the people releasing the code. We get tripped up by the ambiguities inherent in using someone else’s definitions. What, pray tell, is the meaning of “life”? Versioning is naming. Naming carries https://en.wikipedia.org/wiki/Semantics. Thus, all versioning is semantic — numbers, dots, characters, whatever. The ideal to which https://en.wikipedia.org/wiki/Software_versioning#Semantic_versioning aspires is great — and always industrially unfulfilled. It can’t be fulfilled at the level of an industry. > Other schemes impart meaning on individual sequences: > major.minor[.build[.revision]] (example: 1.2.12.102) > major.minor[.maintenance[.build]] (example: 1.4.3.5249) > Again, in these examples, the definition of what constitutes a “major” as opposed to a “minor” change is entirely subjective and up to the author, as is what defines a “build”, or how a “revision” differs from a “minor” change. We can’t get away from subjectivity. It’s not possible and arguably ridiculous. Our responsibility is to be clear about what we are doing, right here, right now. We can save time and energy by skipping appeals to The Truth. No one has time to haggle over the semantics of semantic (or any other) versioning. A release isn’t its name. It’s code. It’s a set of promises and an attempt to fulfill them. Keeping those commitments is good for everyone, developer and community alike. If one isn’t serious about the promises, don’t release. Rich is right: there’s only breakage or growth. Obviously, there are times when the code has its shoestrings tied together. That is, the code has internal inconsistencies, promises that aren’t kept when the code is shipped. The breaking code is in the release. It breaks itself. It’s a bug. It happens. In those situations, the developer has to be even more sensitive to the needs of those who rely on the parts of the code that do work. Hard situations are hard situations. There is no standardized way to handle them because each is as unique as the profile of the promises made, kept, the extent to which those promises are relied upon, and the impact of those vulnerabilities. • How are people affected? • How many are affected? • How seriously are they affected? • How well does the developer understand the how the community uses the code? • How well does the community communicate with the developer? • How well does the community communicate with itself? Many other questions may be situationally and systemically appropriate — and none of them are easy to countenance. Any type of naming is an attempt to communicate something about the nature and number of the promises made. How versions are named or numbered makes no difference beyond the effectiveness of the communication. There’s no place to hide. No naming syntax can compensate for broken promises or make broken promises somehow unbroken. It’s a matter of what can be done with the code and how it is being used. The name of the release means what the developer makes it mean through what he/she/they delivers. It’s on the developer to communicate in all things, including what release names mean. Period. It’s about the relationship. Rich points out that the etymology of “change” is rooted in exchange. Yes. Relationship. We’re talking about our lives here. For me, “breaking people” (thanks @christian767) isn’t as fun as watching them grow — and breakage happens. Being human, parts of me are broken and that brokenness leaks into my code (and my Slack posts). May I be careful, productive, and clean up my messes responsibly. May we be better versions of ourselves through meaningful, deliberate service to our communities. Let’s grow together.