intake-stac 0.3 release plan

[scottyhq]

I propose making a new release that is compatible with more recent STAC versions. Happy to follow this up with a PR, but want some versioning feedback first. cc @jhamman @matthewhanson @andersy005

Currently the sat-stac dependency has a minimum pin, and we've only worked with STACv0.6 catalogs

intake-stac/requirements.txt

Line 3 in d71b2d2

sat-stac>=0.1.3

sat-stac	STAC
0.[1,2].x	0.6.x

There have been a lot of changes in recent STAC versions leading to the 1.0 release. I envision most catalogs will be >1.0 going forward so backwards compatibility isn't a great concern. So I suggest for an intake-stac 0.3 release we pin to sat-stac==0.4.*:

The table below shows the corresponding versions between sat-stac and STAC:

| sat-stac | STAC  |
| -------- | ----  |
| 0.1.x    | 0.6.x - 0.7.x |
| 0.2.x    | 0.6.x - 0.7.x |
| 0.3.x    | 0.6.x - 0.9.x |
| 0.4.x    | 0.6.x - 1.0.0-beta.1 |

We could use this STAC 1.0.0-beta1 endpoint for testing https://earth-search.aws.element84.com/v0/collections since it is the default in the sat-search library.

[matthewhanson]

I agree, with the STAC Sprint coming up the goal is to get catalogs and tools up to date.

Another possibility here though is to switch to PySTAC, which has not yet been released for 1.0, but is very close. PySTAC has some nice functionality, such as being able to specify custom upload/download functions allowing it to be used with cloud object stores pretty easily. I've got a few other features I'd like to see added to it to make it even more suitable.

We could do a 0.3 release with updated sat-stac, but then revisit this during/after the STAC sprints and see about switching to use PySTAC.

[jhamman]

@scottyhq - thanks for opening up this long overdue issue. I'm all for bringing our dependencies up to date so go to town on a PR. Happy to review when things come around.

@matthewhanson - do you have a collection of test stac catalogs for different versions? How do want to handle backward compatibility?

And +1 on moving to PySTAC if that is where the world is headed. Sounds like we can hold off on that for a bit but is something we want to strongly consider adding to the roadmap (xref #43).

[scottyhq]

closed by #61