3 ms·
The author is just not familiar with mature software engineering process. I wish the open source world was more attentive to proper release compatibility, it wo
by jjav 6y ago
The author is just not familiar with mature software engineering process. I wish the open source world was more attentive to proper release compatibility, it would make everyone's life so much better. It does take a bit of discipline but it's really not difficult at all.
At Sun there was strict adherence to release taxonomy and interface contracts, along the lines with what has recently been getting called "semantic versioning".
An interface was anything something external could depend on. Any library or other code must document its public interfaces. That's not just API calls, but all public touch points something might depend on. The author gets to decide what is part of the public and what isn't. That documentation is the contract.
If anything in the set of public interfaces ever changes in an incompatible way, that forces a major release increment. Ideally you never do that. But if you must, it's a new major release number so everyone knows.
Having this documented contract makes everyone's life easier and more predictable. Consumers of the library know exactly on which interfaces and behaviors they can count on not ever changing unless the major release number changes. The author of the code knows exactly when they need to declare a new major release.
Personally on all my open source projects I faithfully maintain this discipline, so if you depend on 1.x of anything I write, it will never break compatibility on public interfaces until I call it a 2.0 and then you know.
- hynek 6y agoYou lead with dunking on the author (yes, me) for describing a reality that you later acknowledge yourself. The article only says that SemVer in practice cannot be relied upon and describes ways how to deal with that fact of life. Nothing else.
- firephreek 6y agoBetween opening up with "Over the years, well-intentioned people experimented with adding meaning to those numbers..." and a reference to Hyrum's Law, your article definitely reads as a criticism of SemVar and pins it as a failed process. It isn't until 1/3 of the way through that you call out the actual failure in the process: The user. Personally, I think the 'failure' of Semvar is in large part the fault of the Node community and their lack of rigor in their releases. SemVar works fine if used correctly.
- hynek 6y agoThat's not part of the article, but I indeed think that a process that (almost) nobody applies correctly, is not a good process. Telling people to just try harder is never the solution to anything. I acknowledge the value of SemVer both here and in the article, but in the practical world it simply does not deliver the value that its proponents claim and users have to deal with it. The article is supposed to help with that.