Tom Mueller wrote:
At some point in the future, it's going to become important to accurately determine whether a public API is incompatibly changing. This is a type of subtle, incompatible change to an API that we should all know about. Making this type of change in a compatible way depends on having the parameters that are passed into the interface correctly defined, e.g., requiring that the argument be derived from some base class so that when a new method is added to the base class, it has some reasonable default behavior rather than raising an exception.
...
breaks with a NotImplementedError after the change? Would that convince you that this really is an incompatible change to ImageInterface?
No.
All I'm looking for is that we acknowledge that this really is an incompatible change to ImageInterface. We have to acknowledge incompatible changes if we are to avoid them in the future.
As you've pointed out, the API has never clearly defined what a 'progresstracker' is, and only asks for one. And as I already mentioned, yes, the usage of the progresstracker of the API could be considered to be changing incompatibly.
However, the catch is that the "incompatibly" part is wholly dependent on the definition of the ProgressTracker class, whether a client is even using that class.
Despite all of this, in terms of pkg.client.api.version, the api is *not* incompatibly changing. I'm not willing to increment the minimum pkg.client.api.version because of a lack of clarity in the documentation or architecture of the progresstracker or because of the need for clarification in the API documentation.
As currently defined by pkg.client.api, this change is not an incompatible one. If that definition is wrong, then it can always be corrected.
Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
