Hacker News new | past | comments | ask | show | jobs | submit login

> just use the commit hash

Does the author honestly fail to realize that commit hashes are incomprehensible to most humans and look like noise, it takes extraordinary mental effort to compare them? While difference between 1.2.3 and 1.4.5 is instantly apparent to any human?

> Pinning is absolutely crucial when building software from some sources out of your control

Amen. I am surprised how the author does not recognize it.

In fact, the only idea that does not come as outright false immediately after reading is "if you change behavior, rename". But thinking about it for a bit, it is wrong too. First, naming is hard. Finding good recognizable name for a package is hard enough, if each BC break would require a new one, we'd drown in names. Second, behavior breaks are not total. If RoR or ElasticSearch releases a new version with BC break, they do not stop being essentially the same package just with somewhat different behavior. Most of the knowledge you had about it is still relevant. Some pieces are broken, but not the whole concept. New name requires throwing out the whole concept and building a new one, essentially. It is not good for incremental gradual change.




My reading of that was that "rename" in that context meant "rename your package from Foo-1 to Foo-2", not come up with a completely brand-new name.


Mine too, eventually. I am surprised that the writer was unable to make even that very simple point clear.


I thought the author did a decent job - he had two examples (Rails-5 and Leftpad-17) that made the point pretty clearly.


it takes extraordinary mental effort to compare them

Worse is that you can't just sort on hashes alphabetically and recover the correct version order. That alone is reason enough to use some kind of sortable versioning scheme.


> While difference between 1.2.3 and 1.4.5 is instantly apparent to any human?

The author's point is that the difference between 1.2.3 and 1.4.5 can be anything from a bugfix to the software going from self-hosted photo software to now it's driving a car. The assumption that users have the same perception of a major and minor version as the developer responsible for the versioning, is assuming that all humans understand versioning 100% identically.


You're overthinking this. The only significant difference between the versions 1.2.3 and 1.4.5 is that 1.4.5 is instantly recognized as the newer version. Can you say the same about two arbitrary commit hashes?


But what is the value in knowing that it is newer, if you know nothing else than that it is newer?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: