<div dir="ltr"><div class="gmail_default" style="font-size:small">We have some services where we provide client tools; when we make some sort of incompatible service change we add a new endpoint (usually a new capability because we are using major.minor versioning of the standardID and matching exactly) and run with both versions for some period of time (until users have updated clients). In this kind of usage (custom clients) a specific version of a client only looks for one version of the capability so as users upgrade client s/w usage moved from the old to the new version. We have not had a need to make clients check minor versions and act differently.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We could do the same with a stable standardID and an @version attr on the interface, which is what the UWSRegExt doc should have said... that approach would let the service advertise new (optional) features that the client could use, so that fits the IVOA minor-version of a service (don't break clients) usage. I never had a need for multiple interfaces with same standardID and different versions because keeping the previous version interface in this case made service more complex and was of no value to users. There could be a use case, but we've evolved some services through many changes and never wanted to do that.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">my 2c,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">PS-These are not IVOA services, just custom web services where clients use VOSI-capabilities to figure out to how to invoke the service<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 June 2018 at 23:46, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Grid,<br>
<br>
On Mon, Jun 25, 2018 at 02:13:34PM +0100, Mark Taylor wrote:<br>
> On Mon, 25 Jun 2018, Markus Demleitner wrote:<br>
> > As long as we have not identified strong use cases to discover by<br>
> > minor version, my take would be: interfaces declare the highest<br>
> > version they implement. That would cover the "I need some extra<br>
> > feature only available since version 1.2" use case, which currently<br>
> > is the only discovery use case I find somewhat credible.<br>
> <br>
> First, we're not just talking about discovery in the registry here,<br>
> this also applies to enumerating interfaces in a service's capabilities <br>
> endpoint, and one can imagine 'discovery' use cases in that context<br>
> that are a little bit more flexible. I agree that it's hard to<br>
<br>
Yes, true. Again, we'll have to figure out the use cases and<br>
requirements for, well, let's call it the VOSI case.<br>
<br>
> advertise in the /capabilities document both a 1.1 and a 1.2<br>
> version - e.g. because the implementation code has changed<br>
> significantly between the two (they have different bugs) and<br>
> they want to allow the (well-informed) user to choose between them.<br>
<br>
Data providers out there: Have you found it necessary to do that?<br>
Based on your previous experience: Do you anticipate that need?<br>
<br>
> Second, I don't think this applies only to minor versions.<br>
> If at some point in the coming decades we have a TAP 2.0<br>
> then there will be reasonable discovery use cases that wish to<br>
> distinguish between 1.* and 2.* versions.<br>
<br>
Current practice with SIA (which I think is sane) is that a major<br>
version gets a new standards record with an identifier of its own and<br>
therefore is, as far as the registry goes, completely independent of<br>
the previous major version. They would therefore have a different<br>
capability element -- which seems quite appropriate to me.<br>
<br>
But I may be fooling myself -- perhaps we should ask on DAL and Apps<br>
if people think the SIA major versioning technique works for them?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
-- Markus<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>