3 ms·
1. That some things are possible 1.x.x that aren't possible in 2+.x.x is a fact that nobody would deny, and is consistent with semantic versioning. The point is
by seliopou 12y ago
1. That some things are possible 1.x.x that aren't possible in 2+.x.x is a fact that nobody would deny, and is consistent with semantic versioning. The point is to clarify the vague terms of "compatibility" and "breaking" by tying them to semantics of the library, as described above. Ultimately, this is a determination made by the developer. Any responsible operator is going to test before deploying, and that's how it should be regardless of versioning scheme.
2. In combination with automated testing, it can go a long way.
3. The first part doesn't make any sense to me. As to the second part, semantic versioning and a changelog are not mutually exclusive. In fact, the practice of maintaining semantic versions typically leads to much higher quality changelogs.
4. Yes, the question is: If not semantic versioning, then what?
- taeric 12y agoFor me, the answer would be conscious upgrades of dependencies with a thoughtful view of the changelog. Of course, I think I would also prefer less of a web of dependencies between so many different things now. It is almost comical. A few years ago, the complaint was that something like Java's JButton would have upwards of 160+ methods from the web of interfaces and superclasses it came from. Seems that today, that web "you can't possibly comprehend it" lies more in the dependencies of a product than in the individual classes. And this only gets worse as some dependencies grow to encompass more and more.