Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EffVer: Version your code by the effort required to upgrade

jacobtomlinson.dev

Post reply on HN
Print view View original

21–30 of 47 posts

Re: EffVer: Version your code by the effort required to upgrade

#21

Post by samatman »

chacham15 wrote: post #12
dmurray wrote: post #10

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".

Its an idealistic view which will almost certainly fail. Test suites, as much as we like to hope that they reflect real usage, mostly dont. A simple example: if function a gets changed from o(n) to o(n^2) but otherwise behaves identically, most test suites will still pass, but if a user has that function in its own inner loop you can go from o(n^2) to o(n^2^2) which can definitely break a lot of things (simple exampl…

You're allowed to fix bugs introduced by new releases, you know. It's called a patch release?

Is your claim that a release which introduces bad algorithmic complexity requires a major release to fix in semver? Who thinks this?

Re: EffVer: Version your code by the effort required to upgrade

#22

Post by KTibow »

medstrom wrote: post #16
codetrotter wrote: post #15

Earlier quoted context omitted.

> 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

What is "based on an embedding"?

There's a thing called an embedding that comes from an embedding model. You put text in and you get a vector (embedding) out. Since the vector represents the text, it's usually used for stuff like search.

Re: EffVer: Version your code by the effort required to upgrade

#23

Post by CuriousCosmic »

krainboltgreene wrote: post #7

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.…

I don't think that's really necessarily fair.

A major version of zero means pre-release code. i.e. a codebase under active development (with the implicit assumption that there will likely be major breaking changes).

A major version of zero just means "I am not committing to a stable API until 1.0" which is a completely fair stance. I'm not going to write code that's very clearly unstable and in active churn and try to pretend it's stable. I'm also not going to keep around a legacy API at that point yet.

Compare that to a standard bump in major version (i.e. 1.0 to 2.0). In this case there is an expectation of a migration path and in all likelihood a versioned legacy API that'll stick around so that users can slowly migrate across the breaking changes between API versions.

Frankly I'm not going to commit to doing that for 0.X.Y/indev projects.

Re: EffVer: Version your code by the effort required to upgrade

#24

Post by dxdm »

samatman wrote: post #19
falserum wrote: post #13

Earlier quoted context omitted.

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…

> For a library there is API and there are implementation details. What if test depended on implementation detail? 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 AP…

The point of the criticism is that defining the version and what constitutes a breaking change like this will still leave people with unexpected breakage in the real world. What you've said so far has not really addressed that point straight on, which might be the reason for the comments and downvotes, I presume.

I don't think your proposed scheme needs to be perfect in that regard, but acknowledging the concern and at least putting it in perspective would probably help.

Re: EffVer: Version your code by the effort required to upgrade

#25

Post by samatman »

dxdm wrote: post #24
samatman wrote: post #19

Earlier quoted context omitted.

> For a library there is API and there are implementation details. What if test depended on implementation detail? 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 AP…

The point of the criticism is that defining the version and what constitutes a breaking change like this will still leave people with unexpected breakage in the real world. What you've said so far has not really addressed that point straight on, which might be the reason for the comments and downvotes, I presume. I don't think your proposed scheme needs to be perfect in that regard, but acknowledging the concern and…

I've no idea what downvotes you're referring to, I'm well into the black on that post. ¯\_(ツ)_/¯

SemVer is just a pinky-swear not to break people's code. In the real world, people's code breaks anyway, and then you get an argument about what's API, and expected behavior, and so on, and so forth.

What I'm proposing is simply to replace the pinky promise with tests. From some of the other comments, I think this point may have been missed: it isn't every test in your test suite, it's the ones marked "API", only.

This is a strict improvement over social-contract SemVer in two ways: one is that the package manager won't let the maintainers break the API tests without a major version bump. The other is that, if you, as a user, are unsure if some behavior is part of the stable API, you can write and submit a test to that package. If that test is accepted, great: that behavior now cannot change without a major version bump, because, again, the package manager will not bundle the package if that test breaks. Furthermore, even on a major version bump, it is instantly clear if that test is still valid, or not, you can just check before upgrading. If they don't accept the PR, you know that it isn't considered part of the API, so you add the test to your own test suite, so that at least you know quickly what broke if they change it.

Re: EffVer: Version your code by the effort required to upgrade

#26

Post by ambicapter »

dxdm wrote: post #24
samatman wrote: post #19

Earlier quoted context omitted.

> For a library there is API and there are implementation details. What if test depended on implementation detail? 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 AP…

The point of the criticism is that defining the version and what constitutes a breaking change like this will still leave people with unexpected breakage in the real world. What you've said so far has not really addressed that point straight on, which might be the reason for the comments and downvotes, I presume. I don't think your proposed scheme needs to be perfect in that regard, but acknowledging the concern and…

It looks to me like he neatly addressed all concerns that were brought up, even if one does not agree with the solutions he proposes. I don't see any lack of acknowledgment on OP's part.

Re: EffVer: Version your code by the effort required to upgrade

#27

Post by jchanimal »

samatman wrote: post #8

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 describe this idea of an executable feature spec in my roadmap blog post from earlier this year. I agree it’s a great way to think about it.

https://fireproof.storage/posts/roadmap-to-1.0/

We’d define 1.0 in exactly the way you describe, where we can add tests for 1.1 but not remove them without triggering 2.0

Re: EffVer: Version your code by the effort required to upgrade

#28

Post by bbkane »

samatman wrote: post #8

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…

It's a good idea, but I think it still relies on people taking the effort to be responsible, which just doesn't seem to work long term...

Re: EffVer: Version your code by the effort required to upgrade

#29

Post by samatman »

bbkane wrote: post #28
samatman wrote: post #8

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…

It's a good idea, but I think it still relies on people taking the effort to be responsible, which just doesn't seem to work long term...

That's always a risk! One of the strengths of the proposal is that if a maintainer slacks on defining a solid API testset, users can submit the tests they think belong. At that point the responsibility is baked in: once a test is added, you either keep it green or bump the version, enforced by the registry.

If a maintainer staunchly refuses to define an API, that's useful information, the kind you can't get with standard SemVer, where the only mechanism is trusting strangers to do the right thing. Which, to be fair, works ok, some of the time.

Re: EffVer: Version your code by the effort required to upgrade

#30

Post by abathur »

samatman wrote: post #8

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 fiddled around a little with the idea of test-driven versioning a while back. Maybe you'd find it interesting. https://github.com/abathur/tdver

I did draft a git-based implementation (https://github.com/abathur/tdverpy), but it just obviously can't be as compelling as one that was part of a language's native tooling/ecosystem could be.

Post reply on HN