Use main instead of to dev/master

.circleci/config.yml

@@ -107,5 +107,5 @@ workflows:
             tags:
               only: /^v.*/
             branches:
-              # Only dev branch, not PRs
-              only: dev
+              # Only main branch, not PRs
+              only: main

.github/pull_request_template.md

@@ -9,7 +9,6 @@
 
 **PR Checklist:**
 
-- [ ] This PR is made against the dev branch (all proposed changes except releases should be against dev, not master).
 - [ ] This PR has **no** breaking changes.
 - [ ] This PR does not make any changes to the core spec in the `stac-spec` directory (these are included as a subtree and should be updated directly in [radiantearth/stac-spec](https://github.com/radiantearth/stac-spec))
 - [ ] I have added my changes to the [CHANGELOG](https://github.com/radiantearth/stac-api-spec/blob/dev/CHANGELOG.md) **or** a CHANGELOG entry is not required.

CONTRIBUTING.md

@@ -16,21 +16,19 @@ for ideas on projects to advance STAC.
 
 The SpatioTemporal Asset Catalog API specification is under active development. 
 
-The `master` branch aims to always be stable, meaning that all the pieces of the specification are consistent and well
-explained, and all the examples are consistent with the specification. The `dev` branch is a place of active development, 
-where a new change in one part of the spec might not yet be fully updated everywhere else. The team uses the 
+The `main` branch is a place of active development, 
+where a new change in one part of the spec might not yet be fully updated everywhere else. Releases are tagged. The team uses the
 [stac-api-spec issue tracker](https://github.com/radiantearth/stac-api-spec/issues) to identify and track all that will be done for 
 a release. Once all the major issues are resolved the core team makes sure everything is consistent across the spec and
 examples.
 
 ### Submitting Pull Requests
 
 Any proposed changes to the specification should be done as pull requests. Please make these
-requests against the [dev](https://github.com/radiantearth/stac-api-spec/tree/dev) branch (this will
-require you to switch from the default of 'master', which we keep so it displays first). 
+requests against the [main](https://github.com/radiantearth/stac-api-spec/tree/main) branch.
 
 Creating a Pull Request will show our PR template, which includes checkbox reminders for a number
-of things, including adding an entry the [CHANGELOG](CHANGELOG.md) and making the PR against the `dev`
+of things, including adding an entry the [CHANGELOG](CHANGELOG.md) and making the PR against the `main`
 branch. 
 
 All pull requests should submit clean markdown, which is checked by the continuous integration
@@ -42,7 +40,7 @@ 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. 
 
 All pull requests additionally require a review of two STAC core team members. Releases are cut
-from dev to master (and require 3 approvals).
+from main and require 3 approvals.
 
 ### Check files
 
@@ -110,9 +108,6 @@ with a coherent whole.
 and there are no typos, errors, etc.
 - **Update the Changelog**: The [changelog](CHANGELOG.md) should be reviewed to make sure it includes all major improvements
 in the release. And anything in 'unreleased' section should move to the version of the spec to be released.
-- **Merge dev to master**: As there is no 'build' process, since the specification *is* the markdown files in the github
-repository, the key step in a release is to merge the `dev` branch into `master`, as `master` is the current stable state 
-of the spec.
 - **Check Online API Docs**: Check to make sure the online API docs reflect the release at <https://api.stacspec.org/> 
 (this step may go away once we are confident this works well, as this publishing is in flux)
 - **Release on Github**: The final step to create the release is to add a new 'release' on 
@@ -132,7 +127,7 @@ vX.Y.Z-RC.1. The core STAC community should be told and encouraged to update the
 should be updated to the new specification before there is a real release. And ideally an API client is also 
 updated. This provides the core sanity check. If there are changes or fixes to the spec or 
 schemas needed from their feedback then make fixes and do RC2. If it is just fixes to the examples or tooling then no 
-additional RC is needed. After there is no more changes to spec or schemas then the release process should be done on master,
+additional RC is needed. After there is no more changes to spec or schemas then the release process should be done on `main`,
 with no changes to the spec - just updating the version numbers.
 
 ## Governance 

README.md

@@ -4,24 +4,31 @@
 # STAC API
 
 - [STAC API](#stac-api)
-  - [Releases](#releases)
+  - [Releases (stable)](#releases-stable)
+  - [Development (unstable)](#development-unstable)
   - [About](#about)
   - [Stability Note](#stability-note)
   - [Maturity Classification](#maturity-classification)
   - [Communication](#communication)
   - [In this repository](#in-this-repository)
   - [Contributing](#contributing)
 
-## Releases
+## Releases (stable)
 
-- [v1.0.0-rc.1](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-rc.1)
+- [v1.0.0-rc.1](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-rc.1) (latest)
 - [v1.0.0-beta.5](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-beta.5)
 - [v1.0.0-beta.4](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-beta.4)
 - [v1.0.0-beta.3](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-beta.3)
 - [v1.0.0-beta.2](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-beta.2)
 - [v1.0.0-beta.1](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-beta.1)
 - [v0.9.0](https://github.com/radiantearth/stac-api-spec/tree/v0.9.0)
 
+## Development (unstable)
+
+The [main](https://github.com/radiantearth/stac-api-spec/tree/main) branch in GitHub is
+used for active development and may be unstable. Implementers should reference one of
+the release branches above for a stable version of the specification.
+
 ## About
 
 The SpatioTemporal Asset Catalog (STAC) family of specifications aim to standardize the way geospatial asset metadata is structured and queried.

extensions.md

@@ -88,7 +88,7 @@ Please contact a STAC maintainer or open a Pull Request to add your extension to
 | Name                                                                       | Scope                               | Description                                                                                                                                    | Vendor                                         |
 | -------------------------------------------------------------------------- | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- |
 | [Free-text Search](https://github.com/cedadev/stac-freetext-search)        | [Item Search](item-search/) request | Adds `q` parameter and free-text search against item properties                                                                                | [CEDA, STFC, UKRI](https://github.com/cedadev) |
-| [Context Collections](https://github.com/cedadev/stac-context-collections) | [Item Search](item-search/) request | Adds a `collections` keyword to the [context](https://github.com/radiantearth/stac-api-spec/tree/master/fragments/context) extension response. | [CEDA, STFC, UKRI](https://github.com/cedadev) |
+| [Context Collections](https://github.com/cedadev/stac-context-collections) | [Item Search](item-search/) request | Adds a `collections` keyword to the [context](https://github.com/radiantearth/stac-api-spec/tree/main/fragments/context) extension response. | [CEDA, STFC, UKRI](https://github.com/cedadev) |
 
 ## Creating new extensions