11–20 of 47 posts
(I realise that TLAs have a limited namespace and are bound to have multiple meanings in many contexts, but The EFF is quite a prominent and well-established use in the computing/software arena.)
The only issue with SemVer is that it's a social contract. There's an available solution to this: make it a technical contract instead. Most languages these days have a built-in test suite. They can define "no breaking changes" so that it actually means something. Have a set of tests called API. During a major release cycle, you can add tests, but you can't change the tests you have, and the tests have to keep passin…
I don't know why this got downvoted; it's at the very least an interesting proposal. Would love to hear a critique arguing that it's a terrible idea. Existing package managers could even implement it in a completely backwards- compatible way: if you as a package maintainer don't care for it, you simply never add "API tests".
The only issue with SemVer is that it's a social contract. There's an available solution to this: make it a technical contract instead. Most languages these days have a built-in test suite. They can define "no breaking changes" so that it actually means something. Have a set of tests called API. During a major release cycle, you can add tests, but you can't change the tests you have, and the tests have to keep passin…
I don't know why this got downvoted; it's at the very least an interesting proposal. Would love to hear a critique arguing that it's a terrible idea. Existing package managers could even implement it in a completely backwards- compatible way: if you as a package maintainer don't care for it, you simply never add "API tests".
1. For a library there is API and there are implementation details. What if test depended on implementation detail?
2. What if tests had undisputable bug?
3. Test refactoring requires major release now?
4. Realistically test suite will have some execution paths not covered.
I like the idea of running same tests over multiple versions, to observe changes. But I disagree that it would automate semver. (Maybe in very limited subset of cases)
P.S. Not an actual downvoter, but if I would have downvoted, these would have been the reasons.
There are many 'pros' to this approach: it's stupidly simple and tools can autogenerate it easily, it's trivially sortable, it tells you how long ago the release happened, but above all it intentionally conveys nothing about your perception of the magnitude of changes and therefore is never misleading. The real meaning is conveyed via release notes: high level changes (with emphasis on any breaking changes) followed by a detailed changelog.
I understand the desire to convey more meaning in the version number itself, but every alternative approach I've tried always falls apart in some way and/or becomes more trouble than it's worth, especially when it's a marketing person who wants version numbers to get bigger faster or a "humble" team member who is anxious to call this the 1.0 release.
Stuff like SemVer seems like a good idea initially, but even with a rigorous test suite there are cases where a bug fix or new feature aren't quite as backwards compatible as intended, so trust in the version number only goes so far. Or it tends to give undo emphasis, e.g. in this release you are pushing out several backwards compatible bug fixes and you are finally pulling a feature you deprecated a long time ago. You have good evidence that nobody has used this feature in years, and for all intents and purposes this is a very small patch release, but you instead have to bump the major version, implying that it's a big release.
Something like EffVer is an interesting approach, but when it ends up being inaccurate for you (i.e. when a supposedly painless upgrade is anything but), then all it has done is pour salt on the wound.
EffVer ignores that different users will experience different amounts of pain, not solving the complaint it has about SemVer. If 99% of your users need to do nothing but 1% of your users are going to need significant effort to migrate (say, retiring a couple version old schema most users never even used) then macro/meso/micro all fail to communicate the expected amount of pain. Similarly, if you take the attitude eve…
I hear ya. So what what we should be doing is to make a 4096-dimensional vector based on an embedding created from our release notes. And use that as the release version :D
EffVer ignores that different users will experience different amounts of pain, not solving the complaint it has about SemVer. If 99% of your users need to do nothing but 1% of your users are going to need significant effort to migrate (say, retiring a couple version old schema most users never even used) then macro/meso/micro all fail to communicate the expected amount of pain. Similarly, if you take the attitude eve…
> That said, start trying to include so much information in the version string and eventually you'll just end up with a compressed version of the release notes and not a version number. I hear ya. So what what we should be doing is to make a 4096-dimensional vector based on an embedding created from our release notes. And use that as the release version :D
Any versioning mechanic that allows for a `0.X.Y` has ultimately failed it's users. There are libraries on almost every package manager that have millions of downloads, thousands of production users, but still pretend they are `0.X.Y` as if that means anything. I mean just think about what this sentence: zero version still denotes a codebase under development A human wrote that and said "Yeah, this makes sense to me.…
Though that'd communicate something totally different from EffVer... Bumps in my X are not "macro effort".
Isn't the effort relative to what you're currently running? If the micro version you're running is 100 versions behind, is it still expected to be micro effort?
Earlier quoted context omitted.
I don't know why this got downvoted; it's at the very least an interesting proposal. Would love to hear a critique arguing that it's a terrible idea. Existing package managers could even implement it in a completely backwards- compatible way: if you as a package maintainer don't care for it, you simply never add "API tests".
I would not call it terrible, but I got a “silver bullet” vibe, which it is definitely not. 1. For a library there is API and there are implementation details. What if test depended on implementation detail? 2. What if tests had undisputable bug? 3. Test refactoring requires major release now? 4. Realistically test suite will have some execution paths not covered. I like the idea of running same tests over multiple v…
If the test is in the API testset, it's API. If it isn't, it's an implementation detail.
> What if tests had undisputable bug?
If it's in the API testset, time for a major version bump. If not, fix it.
> Test refactoring requires major release now?
Only if you're refactoring the API, as defined by the API testset, thereby producing a breaking change.
> Realistically test suite will have some execution paths not covered.
Doesn't matter. If the behavior isn't in the API testset, it's not a part of the API.
> But I disagree that it would automate semver.
The point isn't to automate semver, I'm not even sure what that would mean. It's to define it, in a useful and objective way.
EffVer ignores that different users will experience different amounts of pain, not solving the complaint it has about SemVer. If 99% of your users need to do nothing but 1% of your users are going to need significant effort to migrate (say, retiring a couple version old schema most users never even used) then macro/meso/micro all fail to communicate the expected amount of pain. Similarly, if you take the attitude eve…
SocialVer:
- upvote or downvote major release changes
- emojis to communicate the level of upgrade pain
- emojis to communicate the level of disaster after upgrading