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

161–170 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#161

Post by qznc »

gravypod wrote: post #61

I'm a big fan of really simple versioning schemes. . . Any version ending in a "0" is stable. IE: - 1.0.0 - 0.1.0 ..... - 999.999.0 Whenever you are doing a "release" you have tested every feature fully to make sure the software is up to spec. Whenever you are doing a "rewrite" you can assume that the software's APIs have changed and you will need to readjust compatability (ideally APIs never break but this is one ex…

I like `git describe --always --tags`. It gives me a string like "v0.4-10-gd7b8" assuming I have tagged my repo with semver like "v0.4". More precisely, that string means 10 commits on top of tag "v0.4" and you checkout revision gd7b8 to get it.

Re: Is Semantic Versioning an Anti-Pattern?

#162

Post by Piskvorrr »

c3534l wrote: post #6

> the labyrinthine process used in Renaissance Italy to elect a Doge I was very disappointed to learn that Italy did not, in fact, elect a Shiba Inu to office.

And worse, this process concerned only the Serenissima (i.e. the area ruled by Venice), not the entire Italy.

Re: Is Semantic Versioning an Anti-Pattern?

#163

Post by davvid »

nstart wrote: post #146
fenomas wrote: post #70

Why is it that every time there's an article criticizing semver, the author never seems to have bothered looking at the spec? > 1. Software using Semantic Versioning MUST declare a public API. That's the very first thing it says. Semver is not meant for general apps or websites or the like, it's for APIs against which dependencies can be declared . If your software doesn't need to tell package managers about its comp…

First thought when reading this article. I fell into this trap too when developing my software stuff and then realised that I was just trying to force something that didn't make sense. My apps don't contain anything that has breaking changes for anyone else. And since then I've become more pragmatic about versioning. Now I don't really bother when it comes to web apps I build. The git commit id hash is good enough fo…

If you need a version number then a very pragmatic thing to do is to just tag the repo something short and memorable once, e.g. "v1", and then use the output of "git describe --first-parent" as your version number from that point forward.

The benefit is that you get the object ID along with an automatic counter of the # of commits since the last tag, which is basically a nice, automatic version number that you only very rarely need to update (by creating a new tag).

    $ git tag -m'app v1' v1
    $ git describe --first-parent
    v1

    # hack hack hack
    $ git commit -m'subsystem: some new feature'
    $ git describe --first-parent
    v1-1-gab2fcd9

    # hack hack hack
    $ git commit -m'subsystem: some other new feature'
    $ git describe --first-parent
    v1-2-gc37ed42
The "v1--" prefix makes it much easier for a human to understand when read in logs, since the numbers are typically incrementing, and the strings are understood by Git as valid object IDs so it's easy to lookup the commit.

Re: Is Semantic Versioning an Anti-Pattern?

#164

Post by Piskvorrr »

quickben wrote: post #35

People write software for money, and sell it for money. Version N comes with one year of support, or until version N+1 clocks. Enterprise software sells for even more money, and the above is even more true, usually backed up with lawyers, PR campaigns, etc. Windows 7, 8, and 10, sound to the average person more reasonable that: (from the article): 1612.0009, 1612.0013, 1701.0253 Thus, they are not only a rock solid p…

Funny you should mention Windows - while only the major version is used, there's always a build number associated with a RTM version: 7.0.7601, 8.0.9200, 8.1.9600, 10.0.14393 ;)

I agree that an average user only cares for the major component.

Re: Is Semantic Versioning an Anti-Pattern?

#166

Post by Freak_NL »

XorNot wrote: post #155
Freak_NL wrote: post #144

Earlier quoted context omitted.

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

A commit hash indicates no sequence or logical ordering. With a version number I know that libfancy-1.0.1 was released after libfancy-1.0.0, and in the release notes (as well as the source code repository where the corresponding commit is tagged with the version number) I can easily answer the question “What changed between version 1.0.0 and 1.3.4?”.

Just the SHA1-hash makes this all needlessly opaque — I'm a human, not a machine.

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

Whatever makes you think that? From what I have seen free software projects tend to apply their version numbering schemes with a lot more reliability than proprietary software vendors. And of course version numbers don't obfuscate; any developer worth his salt using version numbers will tag the corresponding commit in the source code repository, and any build environment worth working with will provide a 'release' command that does this automatically.

Re: Is Semantic Versioning an Anti-Pattern?

#167

Post by XorNot »

Freak_NL wrote: post #166
XorNot wrote: post #155

Earlier quoted context omitted.

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

A commit hash indicates no sequence or logical ordering. With a version number I know that libfancy-1.0.1 was released after libfancy-1.0.0, and in the release notes (as well as the source code repository where the corresponding commit is tagged with the version number) I can easily answer the question “What changed between version 1.0.0 and 1.3.4?”. Just the SHA1-hash makes this all needlessly opaque — I'm a human,…

Ordering is very different to what semantic versioning is. Semantic versioning proposes that those numbers have meaning and it's important.

Whereas again, what you and I are both saying is "who cares, I want the commit".

Commit + Branch means I can answer the question "is my problem fixed (or are things broken) in the newest version of the code" - which is the actual question semantic versioning proposes to answer but can't.

Adding a release number for human readability is fine (i.e. imply some quick ordering so you can go "oh, this isn't the newest version"). But even then: when putting together systems, that's not a question I ever really find myself asking - the one I'm asking is "are these things exactly the same, and what's the latest I can upgrade to without breaking it (or conversely: which was it working fine on).

Which is why I point out the need for an immutable web at the end there: if we accept version ranges are useless for doing reliable ops work (I believe they are - i.e. you will be testing everything anyway), then in order to know anything about what does and doesn't work, I need the source code and commit logs. I probably don't want to include all of those in every release and I do want to be able to get to new versions, thus the three things I need: upstream location, upstream branch, and commit hash. Everything else is irrelevant, or sugar.

EDIT: And we can derive simple ordering numbers anyway - just count commits on the release branch since the product started. Accomplishes the same thing.

EDIT 2: It's also worth considering though, that incrementing numbers introduce subtle bias - people always want the highest number, and assume it must be better. There's always an urge to upgrade to version 2, even if version 2 might be a complete rewrite and less developed then 1 with an uncertain future. How different it might be if we only talked about branch names and commits - we're on the "beach" branch, but the company has a got a new one for the product called "forest". How different might discussions about "upgrading" be, and consideration of security fix deployment and status.

Re: Is Semantic Versioning an Anti-Pattern?

#168

Post by demircancelebi »

nstart wrote: post #146
fenomas wrote: post #70

Why is it that every time there's an article criticizing semver, the author never seems to have bothered looking at the spec? > 1. Software using Semantic Versioning MUST declare a public API. That's the very first thing it says. Semver is not meant for general apps or websites or the like, it's for APIs against which dependencies can be declared . If your software doesn't need to tell package managers about its comp…

First thought when reading this article. I fell into this trap too when developing my software stuff and then realised that I was just trying to force something that didn't make sense. My apps don't contain anything that has breaking changes for anyone else. And since then I've become more pragmatic about versioning. Now I don't really bother when it comes to web apps I build. The git commit id hash is good enough fo…

I suggest `commitizen` if you are working with a group. We use it with npm package `standard-version` to keep an auto generated CHANGELOG.md file.

Re: Is Semantic Versioning an Anti-Pattern?

#169

Post by rollulus »

davvid wrote: post #163
nstart wrote: post #146

Earlier quoted context omitted.

First thought when reading this article. I fell into this trap too when developing my software stuff and then realised that I was just trying to force something that didn't make sense. My apps don't contain anything that has breaking changes for anyone else. And since then I've become more pragmatic about versioning. Now I don't really bother when it comes to web apps I build. The git commit id hash is good enough fo…

If you need a version number then a very pragmatic thing to do is to just tag the repo something short and memorable once, e.g. "v1", and then use the output of "git describe --first-parent" as your version number from that point forward. The benefit is that you get the object ID along with an automatic counter of the # of commits since the last tag, which is basically a nice, automatic version number that you only v…

I came here to mention exactly this. Being able correlate artefacts with code through embedded versions that contain the output of git describe is worth tons.

Re: Is Semantic Versioning an Anti-Pattern?

#170

Post by kelnos »

XorNot wrote: post #167
Freak_NL wrote: post #166

Earlier quoted context omitted.

A commit hash indicates no sequence or logical ordering. With a version number I know that libfancy-1.0.1 was released after libfancy-1.0.0, and in the release notes (as well as the source code repository where the corresponding commit is tagged with the version number) I can easily answer the question “What changed between version 1.0.0 and 1.3.4?”. Just the SHA1-hash makes this all needlessly opaque — I'm a human,…

Ordering is very different to what semantic versioning is. Semantic versioning proposes that those numbers have meaning and it's important. Whereas again, what you and I are both saying is "who cares, I want the commit". Commit + Branch means I can answer the question "is my problem fixed (or are things broken) in the newest version of the code" - which is the actual question semantic versioning proposes to answer bu…

> Whereas again, what you and I are both saying is "who cares, I want the commit".

I (not the grandparent poster) usually don't just want the commit. I want to be able to look at two versions and have a good idea if they're source and/or binary compatible.

If I do need to deal with the source of the app, hopefully they're doing me a solid and tagging commits with the version number.

> Commit + Branch means I can answer the question "is my problem fixed (or are things broken) in the newest version of the code"

Sure, if you want to sift through a VCS log, which I don't want to do. I want a changelog file that tells me what's in the version I'm running, and all versions previous. That answers that question too, and maintaining a changelog (even if you just dump the output of git's shortlog into it every release) is just a responsible part of release engineering.

> ...which is the actual question semantic versioning proposes to answer but can't.

No it doesn't. Semver exists to help answer the API/ABI compatibility question. It has nothing to do with whether or not your bug is fixed or not.

Post reply on HN