3 ms·

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 f

by gojomo 12y ago

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".

deleted 12y ago
[deleted]
akerl_ 12y ago
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.
- bryanlarsen 12y ago
  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...

by gojomo 12y ago

deleted 12y ago

[deleted]

akerl_ 12y ago

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.

bryanlarsen 12y ago
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...