Hacker News Reader

Comment by rubiquity | Hacker News Reader

> It also doesn't help here that rather than having a rational discussion, the author released what can only be described as a troll package, where every version change becomes a major version.

What exactly about Jeremy Ashkenas makes you think this was done as a way to troll people? He still took a lot of time to make release notes and note all of the changes.

View on HN

I was referring specifically to the underscore-semver package, not the Underscore project as a whole. Using it in actual projects isn't feasible in any way, because it would require that your project and any project you depend on that also depends on underscore-semver specify the exact same version, or else we're back with the same problem as before. And since you won't be a package maintainer for everything your depend on in most cases, that isn't feasible.

He's not released a version that obeys semver, he's released a version that treats any update as a breaking change.

Ah, I didn't realize you were talking about underscore-semver. I'm sure that was done tongue in cheek.

> He's not released a version that obeys semver, he's released a version that treats any update as a breaking change.

SemVer isn't a law. It's a set of guidelines for versioning software in a slightly less arbitrary way. Maybe extra precaution could be taken for something as common as underscore, and to me that is the only argument worth having here.

Maybe I'm biased by not having a widely used open source project, and my judgement is thus clouded by wanting to one day have a community of users for something that I've written.

That said, I do write code and have tools that are used by other groups of people, and have experienced feature requests and suggestions and patches that I don't necessarily agree with, and I've always tried to step back and consider the overall impact on the project rather than my personal preconception of what the project "should" be. I've merged features that I'd never use and adjusted things to make my project more friendly for users who aren't me.

I think that one of the greater things about open source projects is that over time the original author can focus more on the fun parts or on guiding the overall direction of the project, because the community can provide assistance with identifying issues and maintaining existing systems. Whether the version number is 2.0.0 or 1.7.0 or 50.0.0 is such a trivial thing, and as a developer I'd imagine I'd make my choice based on what made my project more usable for the community.

I think underscore-semver is "ha, ha, but serious". It does fix the problem of protecting people from what might be breaking changes, while freeing the author from having to carefully track changes. It implies: you should upgrade your Underscore if and only if you've made a conscious, aware decision to do so.

I think it's OK for an open-source project – a freely-offered gift to the world – to take that approach, if the author prefers to be personally indifferent about "breaking changes". It's a sort of technical declaration of "NO WARRANTIES", specifically no warranty of "FITNESS FOR A PARTICULAR PURPOSE" – that purpose being, "painless drop-in where a previous version was used".

Yes, but due to the nature of dependencies, it becomes crazy to use in practice. Imagine I write "leetapp", and it depends on "underscore-semver 170.0.0", "tablething 1.0.0", and "otherstuff 2.1.3". Except tablething also uses underscore, so it too depends on "underscore-semver 170.0.0". Now Underscore puts out a new version. I cannot update my app to use 180.0.0 until tablething's devs also do so, or else our dependencies will not be resolvable. This isn't too bad if I only have one dep, but what if I have 20 dependencies that all, somewhere in their dependencies, need underscore-semver?

This is the reason that semver and ranges of dependency management became useful in the first place, because I can say that leetapp needs underscore-realsemver (1.6.0-1.6.n), and tablething can say it needs version (1.6.3-1.6.n) and so forth. This works with sane semver because we can use the parts of the version string to agree on the major API while allowing bugfixes and other improvements to happen without every project needing to bump version numbers.

It depends on what package manager you are using. NPM would allow tablething to use 170.0.0 while leetapp used 180.0.0. Most of the discussion about underscore has been in the context of NPM. Of course your point still stands, because underscore is available in many other package managers, and is very often used without a package manager at all...

The Underscore-semver package is a bit of a troll package — it's the literal-minded SemVer way of versioning Underscore.

Historically, nearly every single release has had at least one thing that mildly changed the behavior of some minor edge case or other. So by strict SemVer, if we wouldn't be at version "170.0.0" by now, we'd be damn close to it.

Why does that matter? Are big numbers inherently bad?

A maintainer did that.

Yup. I'm the contributor who wrote that pull for the release. You can see the original here https://github.com/jashkenas/underscore/pull/1799

Reply on news.ycombinator.com