The initial premise was that the API and "Behavior" have not changed. What
this means for the literal API is pretty clear - that public function
signatures and such are unchanged. "Behavior" is a bit more tricky and
subjective. If you define "behavior" is the strictest possible sense, then
ther
I am not thinking of a certain package.
The singleton problem is just one example.
I'll give you another one:
Let's say my library is a porcelain lib for creating PDFs,
that is using under the hood anthoer library that does
the real work.
So some of the resulting PDF files look different afte
True. That depends a lot on what package we are talking about. You can
check whether that is the case for the specific package in question. Have a
look at the "Avoiding Singleton Problems" section of Russ' article.
IMO it is the responsibility of the package author to make sure, that
different maj
Well on the other hand, if the user has the same dependency imported in the
previous version, there might be surpising effects happening, because she
now has two different incompatible versions of the same package.
If the package is having some init functions that should only be run once
(like
