[regext] Re: RDAP versioning - on client-server interactions and 2-RTT flow

[Mario Loffredo <[e-mail]>]

Hi Andy,

see my responses below.

Il 22/11/2024 21:08, Andrew Newton (andy) ha scritto:
> below...
>
> On Fri, Nov 22, 2024 at 5:00 AM Mario Loffredo
> <mario.loffredo=[e-mail]> wrote:
>> Can you please elaborate on which use case corresponds to support a default version that is six versions back to the next version and no version in between ?
>>
>> Honestly, can't imagine any practical case like the one you described.
>>
>> One coming in my mind is that all the versions between 0.4 to 0.9 could be related to additive changes and the server is able to support all of them.
>>
>> Instead, it seems more likely to me the scenario where the client requests for an extension version not yet supported by the server but supported elsewhere (e.g the client requests for version 0.9, but the higher version supported is 0.8).
> How does this work? If my client requests 0.9 where the JSON
> "foo":"bar" is mandatory but gets back 0.8 where "foo" was never
> defined, wouldn't that cause an error? Is the assumption that a client
> will be programmed to handle both? If so, I don't see that happening.
> I also think it is unlikely that RDAP server operators will support
> multiple versions of an extension in production.

[ML] In making that example,  I was influenced by the definition of 
major and minor versions given by Semantic Vertsioning (semver.org)

/Given a version number MAJOR.MINOR.PATCH, increment the:/

 1. /MAJOR version when you make incompatible API changes/
 2. /MINOR version when you add functionality in a backward compatible
    manner/
 3. /PATCH version when you make backward compatible bug fixes/

Based on it, the increase of the minor version is related to an additive 
(i.e. non breaking) change while the increase of a major versions is 
related to a breaking change (just like adding a mandatory 
property) with a consequent server implementation of a transition process .

Since additive changes don't require the server to manage a transition 
process, multiple versions each one related to an additive change can be 
supported at the same time even on the live platform.

The chain of backward compatible changes gets broken when a breaking 
change occurs.

In that case, the transtion process should be managed on both test and 
live environments.

Clients can decide any time on their own to switch from a major version 
to another major version  with regard to the interaction with a given 
server. However, since servers might implement the same transition 
process but at different times, they should be ready to manage both the 
versions until all of the servers they deal with have completed the 
transition.

On the other side, servers are expected to support both major versions 
for e period to let clients easily manage the transition and avoid 
breaks as much as possible. It may happen that servers extend the 
deprecation period based on the evidence that many clients still don't 
handle the new  version.

> I note that you use the words "additive changes" but the draft says
> "new interface changes" (section 4.2). There probably needs to be some
> language about what interface changes constitute a major bump vs a
> minor bump.

[ML] I agree with you that it should be clarified.

> Earlier in this thread there was a discussion about versioning
> schemes. I don't know where it landed, but there are many more types
> of versioning schemes than semver. A lot of software is going to dates
> like "2024-05". From a CI/CD perspective, a sequence number or
> increasing number scheme is more suitable. I'll also note that at
> present there appears to be only one extension ever to have multiple
> versions: the ICANN gTLD profile. However, it uses opaque versioning
> in the identifier, its documents use major.minor but not necessarily
> semver as elements required in early versions are optional in the
> latest, and the versions are referred to by their year of ratification
> (2019 vs 2024). Food for thought.

I prefer semantic versioning because it conveys the nature of changes 
between versions.

In addition, the versioning_help member already includes the information 
about version start and end time.


Best,

Mario

>
> -andy

-- 
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo