[HN Gopher] EffVer: Version your code by the effort required to ...
___________________________________________________________________
EffVer: Version your code by the effort required to upgrade
Author : hack_ml
Score : 41 points
Date : 2024-02-16 17:58 UTC (1 days ago)
(HTM) web link (jacobtomlinson.dev)
(TXT) w3m dump (jacobtomlinson.dev)
| zamadatix wrote:
| 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 every minor patched bug
| could have users then micro isn't communicating anything
| different than it would have in semver anyways.
|
| If you want to communicate impact it might make more sense to add
| on to semver in some way with a 2 axis "amount of effort" and
| "likelihood it impacts you" as say "-b7" or something. That said,
| start trying to include so much information in the version string
| and eventually you'll just end up with an compressed version of
| the release notes and not a version number.
| rvdginste wrote:
| I still consider semver better. When it is used correctly, the
| version number gives a clear indication of what kind of changes
| to expect when upgrading. Obviously this is done to the best of
| knowledge of the author and might not always be 100% correct.
|
| Either way, the amount of work to do for an upgrade depends on
| which parts of the product you are using and whether those parts
| have any changes in the new version. For this reason, most
| projects also have a changelog which gives you more detailed
| information about the upgrade. When preparing for an upgrade it
| is advised to read the changelog.
| buro9 wrote:
| 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?
| GuB-42 wrote:
| Isn't it essentially generalized semver?
|
| The more breaking changes are, the more effort it is required to
| take them into account. Semver only applies to APIs. Effver could
| apply to UIs too, but for APIs, it would be similar, just not as
| well defined (because it is more general).
| bdjsiqoocwk wrote:
| I didn't understand the objections to semver. Can someone give me
| a specific example of semver failing? I can't think of anything
| other than the package publisher choosing the increment wrong,
| and in that case it's not the versioning mechanism's failure, but
| the publisher's.
| krainboltgreene wrote:
| 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." All
| code is under development until it's not.
| samatman wrote:
| 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 passing. The package registry can run those
| tests, and if any fail, you don't get to post a minor version
| release with that code.
|
| This goes from an underdefined "our API will have no breaking
| changes" to "this is the guaranteed behavior of the API, and
| _cannot change_ until the major version number is bumped ". If a
| downstream user of the package sees some behavior they want added
| to the API contract, they can write a test and submit it as a PR,
| and that test can go into the next release if the maintainers
| agree that it's a stable behavior which they don't intend to
| change.
|
| When you move from e.g. 1.0 to 2.0, the tests which now fail are
| moved to "1.0 API", but they're never removed. No test which is
| ever in an "API" testset can ever be removed, the package manager
| enforces this. Provide some mechanism so users of the package can
| annotate API tests in packages they use as a part of their own
| test suite, so that when they upgrade, those test failing is an
| immediate message about what no longer works. If you only rely on
| behavior which is in common from 1.0 to 2.0, it should be safe to
| upgrade.
|
| No more taking people's word for it when they say "no breaking
| changes", no more bikeshedding about what is or isn't a breaking
| change, just... tests. End of.
___________________________________________________________________
(page generated 2024-02-17 23:00 UTC)