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=40iit.cnr...@dmarc.ietf.org> 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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
