<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 19, 2021 at 10:08 PM Stelian Ionescu <<a href="mailto:sionescu@cddr.org">sionescu@cddr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>It shows that semantic versioning is a bad idea</div></div></blockquote><div><br></div><div>It's not a bad idea. It's badly executed. If humanity would be forbidden to start executing any good ideas because they will be executed badly, we wouldn't be doing anything today.</div><div><br></div><div>If a library says they adhere to semver and they make a mistake, that's a bug as much as a coding mistake is a bug. We have means to point this out to the authors, such as bug trackers. But: the fact that an author releases a version x.y.z doesn't by itself mean they adhere to semver. so maybe the author never intended you to assign this meaning to the version number...</div><div><br></div><div>Maybe we need a way for a system declaration to indicate whether its version adheres to semver or not?</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Erik.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div> unless you have automatic ways of diffing an API between two versions (such tools exist for C), or the development team has the time and resources to very carefully evolve the code.<br></div><div>What one finds in practice is that authors will wing it and increment version numbers if it "feels" like a major change or for publicity reasons (new major release, get it while it's hot!).<br></div><div><br></div><blockquote type="cite" id="gmail-m_-973129933689957004qt"><div dir="ltr"><div dir="ltr"><br></div><div><br></div><div><div dir="ltr">On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov <<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>- etimmons@, rpgoldman@<br></div><div> <br></div><div><div><div>"Erik Huelsmann" <<a href="mailto:ehuels@gmail.com" target="_blank">ehuels@gmail.com</a>>:<br></div><div>> Could you elaborate a bit on "As semver does not work for Common Lisp"?<br></div><div> <br></div><div><div>I've opened an issue in the SemVer github repo: <a href="https://github.com/semver/semver/issues/771" rel="noopener noreferrer" target="_blank">https://github.com/semver/semver/issues/771</a><br></div><div>(Don't want to repeat this explanation over and over in many discussions).<br></div></div></div></div></blockquote><div><br></div><div>"One bad programmer can break more than 10 good ones can fix": the issue you raise is bad engineering (increasing the version number simply because you can) and is not a problem semantic versioning is trying to solve. What it *does* try to solve is that the engineers working on the software can see the problems coming. Applications (and libraries) like Subversion have managed to stay within the boundaries of semantic versioning for almost 20 years now, still "stuck" at version 1.x because of it. At the same time they have succeeded to add significant new features to the software without breaking backward compatibility. So: it's possible. The fact that projects like e.g. Cucumber release a new major version every few months says more about those projects than about semver.<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div> <br></div><div>I will probably refine the issue description in the future, but it should be clear enough already.<br></div></div></div></blockquote></div><div><br></div><div>Regards,<br></div><div><br></div><div>-- <br></div><div dir="ltr"><div dir="ltr"><div>Bye,<br></div><div><br></div><div>Erik.<br></div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.<br></div><div>Robust and Flexible. No vendor lock-in.<br></div></div></div></div></blockquote><div><br></div><div><br></div><div id="gmail-m_-973129933689957004sig4916231"><div>--<br></div><div>Stelian Ionescu<br></div></div><div><br></div></div></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div></div>