The whole section on "just change the name" fits interestingly in with the way that the kernel is developed. They have been rather strict on this for a long time. A function released to the wild stays. Changes to it require a new function.
Spec-ulation – Rich Hickey [video]
21–30 of 74 posts
Re: Spec-ulation – Rich Hickey [video]
#22I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. I got…
His core opposition is to introducing breaking changes under the same namespace. SemVer is the leading scheme that sanctifies such practice.
Re: Spec-ulation – Rich Hickey [video]
#23I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. I got…
His core opposition is to introducing breaking changes under the same namespace. SemVer is the leading scheme that sanctifies such practice.
Perhaps, but he repeatedly claimed that the minor and patch numbers conveyed no meaning, while dismissing the semver spec as a manifesto.
But if he read and understood it, he'd know those were important numbers. Maybe moreso than the major version.
Perhaps he should have argued his actual stance more, instead of the strawman stance. That put me off.
Re: Spec-ulation – Rich Hickey [video]
#24I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. I got…
His core opposition is to introducing breaking changes under the same namespace. SemVer is the leading scheme that sanctifies such practice.
Wouldn't changing the MAJOR version be equivalent to changing the namespace without altering the human memorable identifier of the package?
Understanding that changes in MINOR.PATCH are backwards compatible, is the difference between NAME MAJOR.MINOR.PATCH and NEW_NAME MINOR.PATCH significant? They look to me as just two different conventions.
Re: Spec-ulation – Rich Hickey [video]
#25I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. I got…
Like Rich mentioned from the point of view of a library consumer it's:
PATCH: Don't care MINOR: Don't care MAJOR: You're screwed
MAJOR is simply not granular enough and MINOR and PATCH are pointless.
Sometimes when I update to a new major version of a dependency it all just works. Other times I've got to spend weeks fixing up all the little problems.
Did you break one thing I didn't even use? Update the MAJOR version. Did you completely change the library requiring all consumers to rewrite Update the major version.
Re: Spec-ulation – Rich Hickey [video]
#26This is a worthwhile talk, albeit a bit too long. In this talk RH provides a framework to think about libraries, how they change over time and how we should be communicating those changes. He proposes a way forward in which the changes are communicated in a way that can be dealt with programmatically, a much better framework than versioning schemes (semver gets a beating in this talk!).
Video is a high-bandwidth way of delivering information at a low bandwidth. But try watching tech videos at 1.5 speed, it makes them much more engaging. Also works for ponderous anime.
That's why I prefer youtube over the other services - you can speed it up. I'm not a native speaker, so 1.25 is the fastest I can understand at the moment.
Re: Spec-ulation – Rich Hickey [video]
#27Earlier quoted context omitted.
His core opposition is to introducing breaking changes under the same namespace. SemVer is the leading scheme that sanctifies such practice.
Wouldn't changing the MAJOR version be equivalent to changing the namespace without altering the human memorable identifier of the package? Understanding that changes in MINOR.PATCH are backwards compatible, is the difference between NAME MAJOR.MINOR.PATCH and NEW_NAME MINOR.PATCH significant? They look to me as just two different conventions.
No. Because I don't have a way to keep the old and the new.
That is, the point is that you didn't change my use of the old. You just changed what I actually use. It may work. It may not.
This is especially egregious when I had to up versions to get some new functions, and old versions just happen to have changed.
Re: Spec-ulation – Rich Hickey [video]
#28Earlier quoted context omitted.
His core opposition is to introducing breaking changes under the same namespace. SemVer is the leading scheme that sanctifies such practice.
Perhaps, but he repeatedly claimed that the minor and patch numbers conveyed no meaning, while dismissing the semver spec as a manifesto. But if he read and understood it, he'd know those were important numbers. Maybe moreso than the major version. Perhaps he should have argued his actual stance more, instead of the strawman stance. That put me off.
From the point of view of a library consumer why should they care about the patch or minor versions at all?
Isn't later = better?
Re: Spec-ulation – Rich Hickey [video]
#29I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. I got…
Like Rich mentioned from the point of view of a library consumer it's: PATCH: Don't care MINOR: Don't care MAJOR: You're screwed MAJOR is simply not granular enough and MINOR and PATCH are pointless. Sometimes when I update to a new major version of a dependency it all just works. Other times I've got to spend weeks fixing up all the little problems. Did you break one thing I didn't even use? Update the MAJOR version…
Still don't see the big problem. If the major version is updated and it doesn't affect you, you have a 10 second job to do. If it does, you have a bigger job to do (or don't update).
What's the big deal?
Re: Spec-ulation – Rich Hickey [video]
#30I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. I got…
Like Rich mentioned from the point of view of a library consumer it's: PATCH: Don't care MINOR: Don't care MAJOR: You're screwed MAJOR is simply not granular enough and MINOR and PATCH are pointless. Sometimes when I update to a new major version of a dependency it all just works. Other times I've got to spend weeks fixing up all the little problems. Did you break one thing I didn't even use? Update the MAJOR version…
Being screwed would be the case if the consumer of the artifact is forced to upgrade. i.e.: if versions cannot coexist in a code base.
Otherwise I think the information that they convey is useful:
PATCH: improvement or correction that does not affect the consumers expectation (safe improvement)
MINOR: additional features that may be useful directly to the consumer or its transitive dependencies (safe to upgrade)
MAJOR: No longer safe to upgrade automatically. The consumer may need to investigate further or stay with the previous MAJOR.
In any case it is useful information being conveyed. The consumer decides how to act on it.