13 ms·
That is even worse, because now you have to look at two numbers to see if something's breaking or not. If you change the API, you bump the major. If you don't w
by Sanddancer 10y ago
That is even worse, because now you have to look at two numbers to see if something's breaking or not. If you change the API, you bump the major. If you don't want to bump the major, then either figure out a way to do it with the original API, such as a different number of arguments, or put that module in a package that can be installed seperately. Given your original example, you may have package Foo 1.0 which includes subpackage Bar, but you have subpackage Bar 2.0 which people can install separately if they need to. Bumping the major tells people straight out that things have changed. Two majors means that people have to keep track of two numbers for that -- can you tell at a glance if 54.32.593.3 is compatible with 54.33.594.4, for example.
- eridius 10y agoWith my proposed version scheme, you won't ever get 54.32.593.3. That's kind of the whole point. So instead you'd be comparing 1.2.1.1 and 1.3.0.2, which is a lot easier to read.
- cbdfghh 10y agoThe point of Semantic Versioning is to tell you something. So let's say you have Compiler 5.3.2 It means that the important thing is compiler #5. Upgrading from 4 to 5 is a _Big Deal_. You may have to rewrite all your code. Within 5, you have a version 3. 3 has features A,B,C which 2 doesn't have. Most additions go there. So it should be safe to upgrade. Within that, you have bugfix #2. That _should_ always be upgraded, unless you rely on undocumented features. So it's easy for me to tell if I should upgrade. So upgrading from Apache 1 to Apache 2 may brake config scripts and .htaccess files. Don't upgrade on production build. Upgrading Apache 1.1 to 1.2, See README, Should be fine, do a small test on your testing machine. Upgrading Apache 1.1.2 to 1.1.3. Probably a security fix. Do so. Immediately. --------- The OP's numbering system doesn't tell me anything. should I upgrade 5.4.3.2 to 5.5.0.0? Will it be safe? Probably not. You may have to schedule a full testing load just to be sure. What about from 5.4.3.2 to 6.4.0.0? Same thing. You have to do a full testing. And if you _really_ break old code, do everyone a favor and rename your project (So, no, please don't call Go C++ V.13 or something)
- eridius 10y agoYou seem to be very confused. Upgrading from 5.4.3.2 to 5.5.0.0 with my scheme is no different than upgrading from 54.3.2 to 55.0.0 with traditional semantic versioning. I'm not suggesting any change to the actual model of semver, I'm literally just saying that I want to tack a new component on to the front for human consumption purposes.
- cbdfghh 10y agoIn a library, breaking releases should be far fewer than "regular" feature releases. My point is that if you break code more than a few times in the history of your library, you'll get a revolution. For example, see Python 2->3, which was a relatively "small" fix (which just happened to affect pretty much half of existing string processing code), and PHP, where they seem to introduce and then turn around and remove those features every couple years (mysql, no, mysqli, no, PDO? Are we there yet?)
- eridius 10y agoThere's a big difference between massive sweeping breaking changes, and small breaking changes. What I care about is the ability to do smaller breaking changes, and the new "major" version number that I tacked onto the front is to signify the large sweeping changes instead of the smaller breaking changes.
- lisivka 10y agoAs user, I see no difference because result is same: code is broken. You are trying to introduce full scale for the binary thing. If breaking change is small, then delay it until next major release.
- chj 10y agoSounds like using three numbers is not bad enough.
- eropple 10y ago