STAC versions and deprecated components

[fredliporace]

👋 we talked about this in the last call and I though that this channel would be a good way to continue, although the case we raised is related to stac-api and not stac-spec.

At some point we discussed which version would remove the deprecated Query extension. It is my understanding that the removal is a breaking change, and following semantic versioning guidelines it will not be removed in 1.x but only in >= 2.x

That means, in practice, that Query will be around for many years.

Filter extension greatly extend the search capabilities but there are some concerns on implementation effort and used standards (CQL-JSON is new, etc).

So developers will be faced with two choices when adding basic filter API extension (basic = Query):

• the deprecated Query extension
• the new Filter extension that requires greater development effort and will probably evolve with implementations feedback.

That is a very hard choice for people not familiarized with the discussions. For my particular use case I think that Query would be my choice even if I had to work on a new implementation. This conflicts with the idea that it is not very smart to start an implementation with an already deprecated component.

Maybe we should mark Query as deprecated when Filter is more stable and have some implementations? A possible scenario is Query being deprecated at some 1.x (x>0) version and removed in 2.0.

CC @philvarner

[philvarner]

@cholmes could you setup stac-api-spec with Discussions?

[cholmes]

So my original thinking was that we'd use this discussion forum for everything STAC related, so that we get critical mass, and then could split off it made sense. I fear having 5 discussion forums that aren't really used.

I'm less on that now, since each discussion is pretty tied to the repo, but I'd say we keep it going like this for a bit.

[philvarner]

At some point we discussed which version would remove the deprecated Query extension. It is my understanding that the removal is a breaking change, and following semantic versioning guidelines it will not be removed in 1.x but only in >= 2.x

That is true about semantic versioning, but STAC API is not yet 1.0 -- it is still in beta, so the breaking change rule does not yet apply.

[fredliporace]

Is Query then scheduled to be removed for STAC API 1.0? That was my initial understanding from the deprecated state but now I'm not so sure.

[philvarner]

I'm not sure either -- Chris is advocating for removal, but my preference is that it would still be deprecated, as I think there is still a good use case for it, even if we prefer Query.

[cholmes]

I mostly think it's just really weird to have a '1.0.0' spec that has things that are deprecated. So I'd say if we're not ready to get rid of Query then I'd lean towards having it in 1.0.0 but 'recommending' the use of Filter, and warning that Query may be deprecated soon or something like that.

[fredliporace]

This goes in line with radiantearth/stac-api-spec#157, I removed the WIP state.

[philvarner]

I agree with many of the points you make. I think we're going to be conservative about when Query actually gets removed. With all of the uncertainty about CQL, it might be a good idea to have more precise language about their relationship, rather than simply saying Query is deprecated. I think when I first started Filter Extension last month, we thought it was more "done" and that we'd simply be connecting STAC API and CQL -- but now it seems there's a lot of uncertainty about how CQL will evolve, and we need to wait for that before Filter can be done (or even usable between tools).

[fredliporace]

I'll work on a PR to clarify that.

[fredliporace]

radiantearth/stac-api-spec#157

[fredliporace]

Closed via radiantearth/stac-api-spec@44b0a0b