Major Version Transitioning - IVOA June 2025 Interoperability Meeting

* back to main programme page *

Managing Major Version Transitions (in the VO and beyond)

Time: Tuesday June 3 - 16:00-17:30 (College Park local time)

Location: Room 2309

• Moderator: Markus
• Note taker: Marco -> *Notes: Major Version Transitioning notes
• Lecture notes for the introductory talk

The session will go through

• What’s a “major version”?
• Desiderata for transitioning between major versions
• How we did so far: SIAP, UCD, VOTable BINARY2, ...
• Can we do it properly?

A report/note on this, as well as a place to contribute is available on GitHub/ivoa - major version transition.

Here is a rough transcript of what happened during the session:

(See Markus' Pitch)

Rough summary: breaking changes must be managed, taking in all relevant stakeholders. We will probably drop the server-side economy – service operators in the SIA case did that anyway).A

Identify clear time frames for the tranistion: We need a team to manage the change.

A project to test? P3T proposals? ConeSearch-2.0?

JF: P3T never proposed to replace VOTable XML with JSON, but use JSON perhaps in UWS. An example of successful changes may be USB version changes, which happened without breaking. That they did it and USB-C is now slowly taking up. So: major version changes are slow and costly, but it is valuable in the end.

AR: if you make a better product it will be used, keeping old users and/or welcoming newcomers.

MBT: Plastic and SAMP was a major breaking change that eventually succeeded.

DeLucchi: At Google, code version numbers were built in the code wherever versioned APIs were use. Ich you broke something, it was on you to fix all code that might break. It required resources to do so. Disappointed users was not enough (in commercial) to stop dropping or changing.

RDA: do we want to risk the full community get mad at us?

James Tocknell: is there a way to use the Registry to keep multiple versions? Markus: Yes, but of course that still means that services need to implement both versions.

PLS: we know who is handling the ConSearch-1, we can go contact the providers and try to move depending on what we will possibly lose. Markus: But we will lose the clients that cannot be upgraded; there will always be some of these, and we should have a plan to help people with broken software.

Pat: server-side ecenomy seems the only workable. To minimize the cost is to make the lifetime of the older version short-ish. It will always be the case for a long tail of old clients/versions in use. 24 month could be a good deprecation time. Additional: more small changes are easier than a few big ones, but they annoy people in different ways.

Tess: GCN recent eperience. Old GCN wasn't good. The refresh was a completely separate nicely working system. GCNclassic-over-Kafka was set up to keep the old solution in. Let's have a closer look at how that worked and what the results were.

Tess: Large data providers need to take the community along. Trying to keep alive the old versions is important but requires further resources.

Adrian: For each major version we should properly alert the benefits and provide tools and recipes to help transitioning. Markus: this is exactly "we need a team" and this session is for that.

Mark K.: ssh transition for the encryption algorithms (removed) works quite nicely: The algorithms are not immediately removed but are disabled by default, and you need extra configuration to keep things working. Markus: that's an example of avoiding making breaking changes. The thing with poking people before something finally breaks would really helpful. Can we have a general mechanism to convey warnings for deprecation in responses?

Markus: MBT, what about a "Warning" INFO in VOTable? MBT: It could be an idea, as far as it doesn't prevent working.

Mark CD: was there a plan to make binary2 the mandatory one and drop the binary? Markus: No.

Joshua: standardising message responses (P3T idea & work) could help in this, OpenAPI described.

Tess: what about schema.org?

Pat: There was an attempt to upgrade IRC to XMPP; it was better, there were clients, but IRC still exists (and XMPP is half-dead).

Mark K.: http replaced gopher quite well.

Mark T.: server-side economy should be the one to pursue. However, GBDF, if in attendance, would probably say the opposite.

It is important to have a clear idea of what would be the difficult parts, what need to be dropeed, what pains will be there, we can agree on that and move on.

Who helps with ConeSearch-2? Rubin in for a DALI-ised ConeSearch, Tess and Mark T. also signal they may be in.