Update version numbers to v1.1.0 and update projection extension in examples (#1303)

* Update version numbers, incl. projection extension

* Small corrections

* Update to beta.1

* npm run check -> npm test

* Fix outdated examples

* Fix validation, upgrade CI

* Guess a release date

---------

Co-authored-by: Emmanuel Mathot <emmanuel.mathot@gmail.com>

Author: m-mohr

.circleci/config.yml

@@ -3,7 +3,7 @@ jobs:
   test_examples_node:
     working_directory: ~/stac
     docker:
-      - image: cimg/node:18.18.0
+      - image: cimg/node:lts
     steps:
       - checkout
       - run:
@@ -27,7 +27,7 @@ jobs:
   test_docs:
     working_directory: ~/stac
     docker:
-      - image: cimg/node:18.18.0
+      - image: cimg/node:lts
     steps:
       - checkout
       - run:
@@ -39,7 +39,7 @@ jobs:
   publish_schemas:
     working_directory: ~/stac
     docker:
-      - image: cimg/node:18.18.0
+      - image: cimg/node:lts
     steps:
       - checkout
       - run:

CHANGELOG.md

@@ -1,12 +1,15 @@
 <!--lint disable maximum-line-length-->
 # Changelog
+
 All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
 and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
 
 ## [Unreleased]
 
+## [v1.1.0-beta.1] - 2024-08-08
+
 ### Added
 
 - `bands` is a new field in common metadata to replace `eo:bands` and `raster:bands` ([#1213](https://github.com/radiantearth/stac-spec/discussions/1213))
@@ -499,6 +502,7 @@ See the [milestone 0.4.0 in the issue tracker](https://github.com/radiantearth/s
 Thanks @hgs-msmith, @matthewhanson, @hgs-trutherford, @rouault, @joshfix, @alkamin, @hemphillda, @jeffnaus  and @fredliporace for contributing to the spec directly, and to [everyone](https://github.com/opengeospatial/wfs3hackathon/blob/master/notes/introductions.md#participants) who participated in the [Ft Collins sprint](https://github.com/radiantearth/community-sprints/tree/master/03072018-ft-collins-co) and brought great ideas.
 
 [Unreleased]: <https://github.com/radiantearth/stac-spec/compare/master...dev>
+[v1.1.0-beta.1]: <https://github.com/radiantearth/stac-spec/compare/v1.0.0..v1.1.0-beta.1>
 [v1.0.0]: <https://github.com/radiantearth/stac-spec/compare/v1.0.0-rc.4..v1.0.0>
 [v1.0.0-rc.4]: <https://github.com/radiantearth/stac-spec/compare/v1.0.0-rc.3..v1.0.0-rc.4>
 [v1.0.0-rc.3]: <https://github.com/radiantearth/stac-spec/compare/v1.0.0-rc.2..v1.0.0-rc.3>

CITATION.cff

@@ -8,9 +8,9 @@ preferred-citation:
   type: standard
   title: "SpatioTemporal Asset Catalog (STAC) specification"
   abstract: "Making geospatial assets openly searchable and crawlable."
-  version: 1.0.0
-  year: 2021
-  date-released: 2021-05-21
+  version: 1.1.0-beta.1
+  year: 2024
+  date-released: 2024-08-08
   license: Apache-2.0
   url: https://stacspec.org
   repository: https://github.com/radiantearth/stac-spec

CONTRIBUTING.md

@@ -33,9 +33,9 @@ you to change the base in GitHub's PR creation page.
 select breaking changes, but after 1.0 this will change)
 
 All pull requests should submit clean markdown, which is checked by the continuous integration
-system. Please use `npm run check` locally, as described in the [next section](#check-files), 
+system. Please use `npm test` locally, as described in the [next section](#check-files), 
 to ensure that the checks on the pull request succeed. If it does not then you can look at the
-mistakes online, which are the same as running `npm run check` locally would surface.
+mistakes online, which are the same as running `npm test` locally would surface.
 
 All pull requests that modify or create JSON schema files or examples should use
 [JSON formatter](https://jsonformatter.org/) to keep files consistent across the repo. 
@@ -59,7 +59,7 @@ npm install
 Then to do the check for markdown and examples you run:
 
 ```bash
-npm run check
+npm test
 ```
 
 This will spit out the same texts that you see online, and you can then go and fix your markdown or examples.

README.md

@@ -48,7 +48,7 @@ with additional web service endpoints and object attributes.
 ## Current version and branches
 
 The [master branch](https://github.com/radiantearth/stac-spec/tree/master) is the 'stable' 
-version of the spec. It is currently version **1.0.0** of the specification. The STAC specification 
+version of the spec. It is currently version **1.1.0-beta.1** of the specification. The STAC specification 
 follows [Semantic Versioning](https://semver.org/), so any breaking change will require the spec to 
 go to 2.0.0. 
 

STAC-UML.drawio

@@ -290,7 +290,7 @@ providing them at the Asset level can prove to be very useful for using the data
   extension](https://github.com/stac-extensions/raster) for that use case.
 - `bands` (e.g. in combination with the [EO extension](https://github.com/stac-extensions/eo/)):
   Provide spectral band information, and order of bands, within an individual asset.
-- `proj:epsg`/`proj:wkt2`/`proj:projjson` ([projection extension](https://github.com/stac-extensions/projection/)):
+- `proj:code`/`proj:wkt2`/`proj:projjson` ([projection extension](https://github.com/stac-extensions/projection/)):
   Specify different projection for some assets. If the projection is different
   for all assets it should probably not be provided as an Item property. If most assets are one projection, and there is 
   a single reprojected version (such as a Web Mercator preview image), it is sensible to specify the main projection in the 

STAC-UML.pdf

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://schemas.stacspec.org/v1.0.0/catalog-spec/json-schema/catalog.json",
+  "$id": "https://schemas.stacspec.org/v1.1.0-beta.1/catalog-spec/json-schema/catalog.json",
   "title": "STAC Catalog Specification",
   "description": "This object represents Catalogs in a SpatioTemporal Asset Catalog.",
   "allOf": [
@@ -27,7 +27,7 @@
         "stac_version": {
           "title": "STAC version",
           "type": "string",
-          "const": "1.0.0"
+          "const": "1.1.0-beta.1"
         },
         "stac_extensions": {
           "title": "STAC extensions",

best-practices.md

@@ -162,7 +162,7 @@ Oftentimes it is possible to model data and assets with either a Collection or a
 Items as much as is feasible, as they designed for assets. Using Collection-level assets should only be used if there is not another
 option.
 
-#### Item Asset Defintion
+#### Item Asset Definition
 
 This serves two purposes:
 
@@ -371,6 +371,6 @@ A STAC Collection is a JSON file ([RFC 8259](https://tools.ietf.org/html/rfc8259
 STAC Collections which don't link to any Item are called **standalone Collections**.
 To describe them with more fields than the Collection fields has to offer,
 it is allowed to re-use the metadata fields defined by extensions for Items in the `summaries` field.
-This makes much sense for fields such as `platform` or `proj:epsg`, which are often the same for a whole Collection,
+This makes much sense for fields such as `platform` or `proj:code`, which are often the same for a whole Collection,
 but doesn't make much sense for `eo:cloud_cover`, which usually varies heavily across a Collection.
 The data provider is free to decide, which fields are reasonable to be used.