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

Is Semantic Versioning an Anti-Pattern?

surfingthe.cloud

Post reply on HN
Print view View original

201–210 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#201

Post by taeric »

Sean1708 wrote: post #193
thaumaturgy wrote: post #63

Earlier quoted context omitted.

It used to work that way, though; software in the 90s and early 2000s did have sane semantic versioning, updates were backported to earlier major versions, and revision updates generally didn't break anything in production. I bet semantic versioning is mostly championed by older veterans who have worked in maintenance or systems administration roles and are trying to get the industry to return to a versioning system…

I'm not sure I understand your argument. If someone's not going to backport a v2.1 fix to v1.6, why would they backport a v20170106-1009 fix to v201610-1005?

I'm not sure what you are saying. My argument is that it is a myth that most things will get only security updates.

That is, the version scheme States the point is to somehow be in a position to get only security updates. However, unless there is an org specifically for maintaining a library, your only hope of getting updates is to take all updates. So, to stay on the latest.

Re: Is Semantic Versioning an Anti-Pattern?

#202

Post by stormbrew »

stymaar wrote: post #174
stormbrew wrote: post #117

Earlier quoted context omitted.

Yes, cargo is the package manager, but it is also the build tool. Whether it's a library or a terminal project (one that has nothing depending on it) you use cargo to build it and it has a Cargo.toml. Even if nothing will ever use your package you will always have to have a version field defined in it.

I agree with you, semver doesn't make sens for every project. But it still make sense for a lot of executables, and not only library, let me illustrate that. Let say you create a cli tool, with a given set of command-line parameters. These parameters are the API your programming is exposing. I can use your program from a shell script for instance, and I will use the existing interface. If, in the next release, you ch…

I didn't say "it doesn't make sense for executables". I said it makes sense for terminal projects on which nothing has a versioned dependency. This is usually (maybe always) executables, but not all executables fall under that heading.

edit: Oh I see. I can see how you'd interpret what I said as implying that [all not libraries] are terminal. I wasn't being exhaustive. :)

Re: Is Semantic Versioning an Anti-Pattern?

#203

Post by stormbrew »

steveklabnik wrote: post #188
kazinator wrote: post #185

Earlier quoted context omitted.

Are you saying one can't write a Rust program that is just a simple, unversioned OS native executable without any Rust-this attached, or being embroiled in Rust-that?

You absolutely can. Cargo is not strictly speaking required to build Rust code, it just makes it so easy virtually everyone uses it. rustc won't ask you anything about version numbers.

Yes. To be clear, I am not saying you can't do anything without cargo, but if you depend on any crates it makes very little sense to try to not use it. It only really makes sense to try if you have no external rust dependencies, which I think usually either means you're writing a kernel or a toy.

Re: Is Semantic Versioning an Anti-Pattern?

#204

Post by steveklabnik »

stormbrew wrote: post #203
steveklabnik wrote: post #188

Earlier quoted context omitted.

You absolutely can. Cargo is not strictly speaking required to build Rust code, it just makes it so easy virtually everyone uses it. rustc won't ask you anything about version numbers.

Yes. To be clear, I am not saying you can't do anything without cargo, but if you depend on any crates it makes very little sense to try to not use it. It only really makes sense to try if you have no external rust dependencies, which I think usually either means you're writing a kernel or a toy.

I actually use Cargo in my kernel, with dependencies like https://crates.io/crates/x86

So that just leaves toys :)

Re: Is Semantic Versioning an Anti-Pattern?

#206

Post by ak217 »

flukus wrote: post #89
dpark wrote: post #86

Earlier quoted context omitted.

Which is why I think development should be done without locked packages, locking after testing successfully before the production release. Not taking security patches is bad. Taking down production is also bad.

> Taking down production is also bad I won't say it's ever good, but for most software some downtime isn't the end of the world, certainly better than having security exploits available.

There is also lots of Node software running in environments where downtime is unacceptable. And having uncontrolled dependency churn is a great way to break your CI and demoralize your team. I know I've spent way more time than I care to admit debugging failures in test and production because for some reason there was no subdependency freeze. It's the kind of problem that makes you very frustrated.

This discussion is based on a false dichotomy. Yes, shops can be bad at updating dependencies. That's a matter of culture. Technically, I shouldn't have to constantly scan my dependencies for updates, much less security updates. That's what CVEs and release notes are for. Not freezing the dependency tree in CI and production on account of security updates is a bad pattern.

Re: Is Semantic Versioning an Anti-Pattern?

#207

Post by zilean »

Sean1708 wrote: post #195
zilean wrote: post #181

Earlier quoted context omitted.

> Even the smallest and most stable change can break backwards compatibility This i care about. > fix a bug or add a new feature Not sure why i should care about these tho. > essentially breaking existing integration Not sure why you need 3 numbers to express that. Am i right in that your consumers dont get bugfixes by default because api patch version is changing? How is this working irl? > suggestion of using a dat…

>> fix a bug or add a new feature > Not sure why i should care about these tho. I'm using feature X. Feature X was introduced in version X.Y. Therefore I can't use any version less than X.Y. >> essentially breaking existing integration > Not sure why you need 3 numbers to express that. Am i right in that your consumers dont get bugfixes by default because api patch version is changing? How is this working irl? No. Wh…

> I'm using feature X. Feature X was introduced in version X.Y. Therefore I can't use any version less than X.Y.

But it would work the same way with monotonically increasing version. no?

> When you fix a bug you increment the patch version

I am just trying to understand how semver applies to REST in your case. Never seen anything but single number versioning for endpoints.

Re: Is Semantic Versioning an Anti-Pattern?

#208

Post by stormbrew »

steveklabnik wrote: post #204
stormbrew wrote: post #203

Earlier quoted context omitted.

Yes. To be clear, I am not saying you can't do anything without cargo, but if you depend on any crates it makes very little sense to try to not use it. It only really makes sense to try if you have no external rust dependencies, which I think usually either means you're writing a kernel or a toy.

I actually use Cargo in my kernel, with dependencies like https://crates.io/crates/x86 So that just leaves toys :)

Fair enough. :)

Also, btw, even though I'm saying something vaguely negative about cargo I love that both rust and cargo exist and I've been aware of the work you've been doing since your rails days and always liked what you've done and had to say. Just thought I may as well throw that out there. :)

Re: Is Semantic Versioning an Anti-Pattern?

#209

Post by jonathankoren »

verinus wrote: post #135
jonathankoren wrote: post #38

Given that continuous deployment doesn't have anything like traditional releases, so why bother with semantic versioning at all. You're typically just dealing dates or monotonically increasing build numbers. There's no reason for anything else. Public APIs (including libraries), have traditional releases, and so the distinction between backwards compatible and incompatible versions really do matter. That said, a thre…

SemVer has nothing to do with CD. It's for package management. With a package or lib I don't need (multiple) daily increments as I would not update a lib I use that frequently.

You're right, and yet this article goes on and on about CD how shows that SemVer is broken, because SemVar doesn't support CD.

The article is just bizarre. It's like ranting about how knives suck because they can't easily transport rocks.

Re: Is Semantic Versioning an Anti-Pattern?

#210

Post by steveklabnik »

stormbrew wrote: post #208
steveklabnik wrote: post #204

Earlier quoted context omitted.

I actually use Cargo in my kernel, with dependencies like https://crates.io/crates/x86 So that just leaves toys :)

Fair enough. :) Also, btw, even though I'm saying something vaguely negative about cargo I love that both rust and cargo exist and I've been aware of the work you've been doing since your rails days and always liked what you've done and had to say. Just thought I may as well throw that out there. :)

No worries! I didn't even take it as negative, to be honest.
Post reply on HN