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 there is pretty much no such thing as a patch. But, for these purposes, I would define "behavior" as the contracted behavior. This is why proper documentation for the package as a whole, and any public functions, globals and constants is so critical.
So back to your example. If the package makes no specific guarantees about the internal format of the resulting PDF, aside from its correctness, then is is a patch release. It is generally considered bad form for a user of a package to rely on undocumented internals like this. It is the very definition of fragility. Many a fragile program has broken because it assumed things about the exact formatting of JSON, or XML, or even the text of an error message. If, on the other hand, the documentation has made specific guarantees which will now be broken about the internal form of the PDF, then that, sadly, means a major version change. This, again, is why it is so important that package creators think very carefully about what they do, and don't promise in documentation. On Wednesday, August 15, 2018 at 11:05:01 AM UTC-4, meta keule wrote: > > > 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 after the update, > although > that difference come only from the underlying change of the core lib. > > I can think of lots of variations on this theme. You might say: "It > depends...", > but then with a large project it might take a lot of time to go through > all these > changes and decide, if one would rate them as a breaking change. > > So it boils down to: Am I reponsible for the upstream breakages, if I > "pass them through" > and if not: isn't it a false security to believe in semantic versioning > then? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
