[Numpy-discussion] proposed changes to array printing in 1.14

[Nathaniel Smith]

On Fri, Jun 30, 2017 at 7:23 PM, Juan Nunez-Iglesias <jni.soma at 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