Hi Mario, On 03.07.26 10:51, Mario Loffredo wrote:
Hi,{ML] Unless you are saying that old versions must be kept forever, at a certain time a server decides that it's time to remove the old version because it evaluates low to zero the probability of breaking a client.[snip PK]I just wanted to point out, that fulfilment of this condition can never be stated with certainty by the server "clients have switched from the old version to the new one.".
PK2> No, old version does not have to be kept forever.
PK2> for me not at all. As Client implementer it is very different to see that (a deprecated) API version (extension identifier) is gone, where there is clear signalling about it (RDAP conformance) as opposed to seeing a response which is missing some fields or having the fields with changed syntax and semantics. The code paths that don't break in terms of exception are here even more dangerous that the ones that face an exception.Basically client has no way to tell the server if it switched or not, because it happens only after the response has been received from the server.Also in most cases not every client is even known to the server, when out-of-band approaches would come into consideration. Only in case of restricted access RDAP with authentication of clients this may be considered at all.In terms of interoperability it is something different if the client would notice the extension it used to process is not there any longer as opposed to receiving a response with a known extension identifier but with the content which cannot be processed.[ML] Unless a client implements some sort of defensive parsing, the result seems identical to me.
From the perspective of the effort required for both clients and servers to align their implementation to the new version, the two strategies are not at all comparable.Forcibly maximizing the scope of any breaking change seems messy to me and the opposite of what REST API developers are used to.
PK2> The list as it is now formulated in the draft is exactly based on what REST API developers are used to. See GitHub API Policy [1] as an example. Especially this part: "Breaking changes are changes that can potentially break an integration. Breaking changes will be released in a new API version."
Extension identifier is for me an equivalent of "new API version" for an extension.
[1] https://docs.github.com/en/rest/about-the-rest-api/breaking-changes
I could be wrong, but I believe the direct consequence will be that extension providers will write specifications that define as many sub-extensions as there are core components of the extension (e.g., JSON names, URLs, etc.).PK2> ... I may be wrong as well by thinking that the other consequence would be for extension providers to be very careful about back-compatibility, which in such open and multi-party system like RDAP is a wished outcome. The approach you outline may be a way some people find useful - we'll see.
Conversely, if we want to allow extension providers to choose the scope of a change in their extension (including the option to turn a breaking change into a non-breaking change + a deprecation process of specific extension components), we should ensure that the `exts_list` parameter includes the extension versions as defined in the versioning draft.
PK2> Here I agree, but this is likely a different conversation.
This would provide servers with more information about when it's appropriate to remove the old version.
PK2> which can be indeed useful Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
