On Fri, Jun 30, 2017 at 7:23 PM, Juan Nunez-Iglesias <jni.s...@gmail.com> wrote: > I agree that shipping a sane/sanitising doctest runner would go 95% of the > way to alleviating my concerns. > > Regarding 2.0, this is the whole point of semantic versioning: downstream > packages can pin their dependency as 1.x and know that they > - will continue to work with any updates > - won’t make their users choose between new NumPy 1.x features and running > their software.
Semantic versioning is somewhere between useless and harmful for non-trivial projects. It's a lovely idea, it would be lovely if it worked, but in practice it either means you make every release a major release, which doesn't help anything, or else you never make a major release until eventually everyone gets so frustrated that they fork the project or do a python 3 style break-everything major release, which is a cure that's worse than the original disease. NumPy's strategy instead is to make small, controlled, rolling breaking changes in 1.x releases. Every release breaks something for someone somewhere, but ideally only after debate and appropriate warning, and hopefully most release don't break things for *you*. Change is going to happen one way or another, and it's easier to manage a small amount of breakage every few releases than to manage a giant chunk all at once. (The latter just seems easier because it's in the future, so your brain is like "eh I'm sure I'll be fine" until you get there and realize how doomed you are.) Plus, the reality is that every numpy release ever made has accidentally broken something for someone somewhere, so instead of lying to ourselves and pretending that we can keep things perfectly backwards compatible at all times, we might as well acknowledge that and try to manage the cost of breakage and make them worthwhile. Heck, even bug fixes are frequently compatibility-breaking changes in reality, and here we are debating whether tweaking whitespace in reprs is a compatibility-breaking change. There's no line of demarcation between breaking changes and non-breaking changes, just shades of grey, and we can do better engineering if our processes acknowledge that. Another critique of semantic versioning: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e The Google philosophy of "error budgets", which is somewhat analogous to the argument I'm making for a compatibility-breakage budget: https://www.usenix.org/node/189332 https://landing.google.com/sre/book/chapters/service-level-objectives.html#xref_risk-management_global-chubby-planned-outage -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
