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

151–160 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#151

Post by slavik81 »

flukus wrote: post #130
slavik81 wrote: post #126

Earlier quoted context omitted.

Qt uses it extensively. For big, complex objects like QTextEdit it's probably the least of your concerns, but they do avoid it for simple value types like QPoint.

A good chunk of these questions I'm asking are because I half remember Qt's binary compatibility guidelines from when I did an internship at Trolltech many years ago :) A similar list is here: https://community.kde.org/Policies/Binary_Compatibility_Issu... . It looks like the virtual function restrictions are what I was talking about, that's where pure additions can break compatibility.

If you worked at Trolltech, you almost certainly know more than me. I was just a user of Qt who peeked under the covers occasionally.

Re: Is Semantic Versioning an Anti-Pattern?

#152

Post by irishsultan »

amenod wrote: post #124
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.

Which makes sense. First of all, cargo can't know that nothing will use your package. And second of all, it is possible that this will change once someone sees how great package you've built. OTOH it costs you nothing to put a number there and never change it if there is no need.

It can now that it's not exporting a library and only building executables though.

Re: Is Semantic Versioning an Anti-Pattern?

#154

Post by ben0x539 »

irishsultan wrote: post #152
amenod wrote: post #124

Earlier quoted context omitted.

Which makes sense. First of all, cargo can't know that nothing will use your package. And second of all, it is possible that this will change once someone sees how great package you've built. OTOH it costs you nothing to put a number there and never change it if there is no need.

It can now that it's not exporting a library and only building executables though.

Libraries for shell scripts are made from executables!

Re: Is Semantic Versioning an Anti-Pattern?

#155

Post by XorNot »

Freak_NL wrote: post #144
stormbrew wrote: post #122

Earlier quoted context omitted.

The article is poor, I'll agree with that. But the project I work on that makes me agree with it (that does not currently use rust, but it is something we're looking at) is a low level system component that is continuously deployed across entire clusters. We only ever have two versions active in a cluster at a time (either upgrading or downgrading when something goes wrong). People do not really 'consume' us except i…

For this scenario you seem more opposed to the idea of version numbers in general then Semver. Does your build process tag the build numbers in your code repository? The benefit of Semver (and any sensible versioning system) is that whatever you deploy in production gets a (human readable) version assigned to it, and that version is tagged in your git/hg/svn repo. The nice thing about version numbers such as Semver i…

Why not just have the commit hash?

Version numbers seem to exist purely so proprietary vendors can obfuscate their source code a bit.

If I have the commit hash I can go straight to the exact source code version.

Taken to its logical end goal, really I want three things: commit, upstream branch, and where to find the code.

With those 3 and a little bit of tooling I should be able to go from a version number to the commit log of the current compatible upstream (I guess I'm implying a branch == backwards compatibility but just getting the commit log of really what I want)

We don't need semantic versioning in open source - we need a common immutable web which lets us search on the things which matter.

Re: Is Semantic Versioning an Anti-Pattern?

#157

Post by unsoundInput »

fenomas wrote: post #109
unsoundInput wrote: post #41

Earlier quoted context omitted.

I think this talk makes his opinion on how breaking changes in libraries should be handled (in the context of the JVM ecosystem) very clear: A) avoid breaking API changes B) if you have to do large breaking API changes, that will probably affect alot of dependent projects, make it a new artifact / namespace / library that can live side-by-side with the old version B is actually pretty common in large java library pro…

Isn't semver the best way to do what he's advocating, then? I mean, it's not like people delete 1.3.0 from their packaging system when they release 2.0.0. Incrementing the major version number is semver's way of declaring a new namespace, and once declared, it lives alongside the old ones. What is Hickey suggesting be done differently?

It is about treating new versions with major API breakage as if they were completely new libraries, not as a "maybe, possibly drop-in replacement, iff we use just the right feature subset". E.g. RxJava changed their maven artifact ('io.reactivex:rxjava:1.y.z' -> 'io.reactivex.rxjava2:rxjava:2.y.z') and the package name where in which their code lives ('rx' -> 'io.reactivex'). This makes it possible for both versions to be used at the same time while transitioning, without breaking dependencies that rely on the older version and without having to bother with automatic multi-versioning in buildtools.

With that in place it is questionable what the actual advantage of semver vs a simpler monotonous versioning schema (like build number or UTC date) is.

Re: Is Semantic Versioning an Anti-Pattern?

#158

Post by rcymerys »

I think both approaches are fine, depending on context.

This will definitely work fine for software that's delivered to the users. I don't really care about Chrome's or Gmail's version, especially since the update process is transparent to me. The APIs should be versioned on their own and everything is fine.

On the other hand, I really appreciate when semver is used by libraries (jars, gems etc.). From developer's perspective it really helps with updating these dependencies in your own code - a quick look tells you whether it's just a simple bugfix/patch that probably doesn't affect you or something more serious that you should be careful with when bumping dependency version. Because of that, I wouldn't call it an anti-pattern. I'd say it's rather one of possible approaches that will work fine in some cases and not so well in other.

Re: Is Semantic Versioning an Anti-Pattern?

#159

Post by Piskvorrr »

kaspm wrote: post #60
Groxx wrote: post #49

Earlier quoted context omitted.

Ehhh... at best it argues that it's over-complicated for something that only ever has a single version running everywhere. Like a web service that you control, for which there will never be a way to request "use that old version of the code instead".[1] Which is true. But then why even bother with YYMM.xxxx? Just use a single incrementing integer. Or none - nothing can ever go backwards, so callers are required to ig…

Yeah okay. I think there is a very large group of developers who work in just such an environment: developing web applications that have a "production" version whether they are public internet or internal to companies where the previous version would literally _never_ be consumed. The reason to track a increment in that kind of environment is as a code to align feature requests to a particular release (usually by dat…

The version deployed is 20160215.2.142001 (on 2016-02-15, there were three deploys, with the latest build affecting them being #142001). There's your date, which is additionally free of the uncertainty whether you meant mm/dd/yyyy or dd/mm/yyyy. How is that incompatible with semver? (Nowhere does it say that the numbers have to be single digits. Integers.)

Re: Is Semantic Versioning an Anti-Pattern?

#160

Post by Piskvorrr »

jayflux wrote: post #12

I feel like semver works great in the right context, for example if I'm building an API/Library which other deveopers are using, it helps them to know if there's been a major version bump, breaking change or just general patches. However if it's just software for the end user, such as a web browser, it doesn't make as much sense, what is defined as a breaking change for someone browsing the web? And will they care? I…

Is "no more Flash in this version" a breaking enough change for an end user to care? https://blog.google/products/chrome/flash-and-chrome/

"That version has Flash, that version does not; doesn't make sense to the user to tell them apart." Riiight.

Post reply on HN