Skip to content

Plan towards 1.0 release

Jump to bottom
Phil Varner edited this page Jul 19, 2021 · 8 revisions

Philosophy

A key principle of the STAC specification release process is that there are robust implementations of specifications prior to major version releases. Typically, implementations that support a major version spec release only lag by days or a few weeks. The specifications reflect the implementations, rather than the specifications being a blueprint for implementations. This implies we do numerous beta and rc releases to finely-hone the spec that we know works in the real world, rather than put out something quickly that we hope will work.

Release cadence

  • beta releases will be performed monthly until there are no major outstanding issues to resolve. This is expected to take 3-4 months.
  • RC release will then continue at a pace determined by the number of necessary changes in each RC. These should be expected to be at least as frequently as monthly.

Releases

After 1.0.0-beta.3 and its changes to the Filter Extension, there are no major changes expected. There will be additional functionality added and existing functionality refined. There are numerous implementations of these beta specs already being used in production, and the functionality has generally proven to be sufficient for the uses cases STAC API seeks to cover.

  • 1.0.0-beta.3
    • 158 rework Filter Extension conformance classes to be self-contained to STAC rather than reusing OGC API Part 3
    • Collection API conformance class
    • numerous spec clarifications
  • 1.0.0-beta.4
    • Browsable APIs - this is reflecting existing API behavior and providing best practices
  • 1.0.0
    • At least 3 of the top 6 implementations (stac-fastapi, stacatto, resto, stac-server, stac-cmr, and franklin) pass validation

The primary external limitation on an "ideal" 1.0 release is the finalization of the OGC API Features Part 3 CQL specification, as this is used by the Filter Extension. Because the timeline for finalization of Part 3 is uncertain, we will define the Filter Extension such that it is more self-contained (e.g., uses it's own conformance classes), but still references definitions in the Part 3 drafts. We will then expect to better align with Part 3 after it is final, possibly in a STAC API version beyond 1.0.

The CQL spec is a bit complicated, in that some parts of it that reference OGC API Part 3 may never have STAC API implementations, e.g., the Enhanced Spatial Operators, but we still want to allow implementers to do this if they want. As such, we'll likely only use the implementation of what is currently defined as the the Basic operator conformance classes as a measure of support in STAC API implementations for CQL.

Likewise, it is desirable to have collection-level search sooner rather than later, but there is no specification or implementations of this at present, so this is not a good candidate to go into 1.0.

It is expected that STAC API 2.0 will be released within a year after 1.0. The two primary objectives of 2.0 will be to align the Filter Extension and OCG API Part 3 CQL and include Collection-level Search (https://github.com/radiantearth/stac-api-spec/issues/145). This will also likely deprecate the Query Extension in favor of what will hopefully by that time be a well-supported Filter Extension.

Clone this wiki locally