[OLD] use main branch instead of dev/master

[philvarner]

Related Issue(s):

• update version references and migrate branches to use main instead of master/dev for rc.1 #259

Proposed Changes:

Change branch strategy to use main w/ tags instead of dev/master.

There are two aspects to this change:

1. Changing from using a develop->released branch model to a single branch -- Until now, the dev branch was a rapidly-changing work-in-progress. It made sense to not make this the first thing people saw when they came to this repo. As we converge towards 1.0.0, there will be fewer significant changes in main that are not part of the latest released version. Most repos don't have master or a branch with their latest released version as the default branch, so users are used to main being the development tip.
2. Changing the name of the primary branch from master to main -- This has been a trend in the last couple years, motivated primarily by the origination and metaphorical use of the term "master" because of its use in the chattel slavery system in the United States prior to 1865. A project with a diverse audience should not use terms that are so blatantly offensive.

References:

• https://github.com/github/renaming
• Regarding Git and Branch Naming
• Why GitHub renamed its master branch to main

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)
• I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.

[m-mohr]

Are there any (important) external dependencies (may just be links) that point towards master? Does this need to go through the PSC? Would we align stac-spec, too?

[philvarner]

Yes, I think it should definitely go through the PSC.

I would be in favor of aligning stac-spec too, since it's at 1.0.0 and hasn't had any changes in months.

[cholmes]

Can you write up the reasoning for this? I do think we should do the same thing for stac-spec and stac-api. I'm open to switching it, but just want to be sure I understand the reasoning, etc.

[philvarner]

I will, where should I write it up?

[m-mohr]

Here for now?

[philvarner]

Are there any (important) external dependencies (may just be links) that point towards master?

I'm not aware of any. I plan to leave master around, but we can clearly indicate in the README that you should be using main or the latest release tag instead.

Does this need to go through the PSC?

I should have added the entire PSC as Reviewers -- I've done that now.

Would we align stac-spec, too?

I think we should align stac-spec with this too.

[tschaub]

+1 for naming the default branch main and having the default branch be the base for development.

[cholmes]

I'm fully +1 on naming default branch to main.

I'm ok with default branch being the base for development as long as we add in a 'publish' step for release and host the 'definitive' text somewhere else, like stacspec.org/specs/stac-api or something, and have the readme say 'the latest version of the spec is at stacspec.org, this repo contains the development of unreleased versions' or something.

To me it just doesn't really work if we're doing active development on the default branch if the 'spec' is just the repo, since then people who just go to https://github.com/radiantearth/stac-api-spec/ won't know that the 'stable' thing they're supposed to look at to see the spec is actually a branch, and that the default navigation may lead to changes that have been made but are not yet 'shipped' in a spec release.

[tschaub]

Yeah, the main readme could just be an intro blurb (without deeper links) and links to more detail for the latest release.

Something like ...

---

STAC API

The STAC API defines a JSON-based web API to browse and query SpatioTemporal Asset Catalog (STAC) objects. While the core STAC specification provides a structure and language to describe assets, users usually want to access a subset of the entire catalog, such as for a certain date range, in a particular area of interest, or matching properties they care about. STAC API extensions specify those query parameters, and compliant servers return STAC Item objects that match the user's preferences. A lot of additional functionality can added through the OGC API family of standards, particularly OGC API - Features (OAFeat, for our shorthand).

Description	Version
Latest release version	v1.0.0-rc.2
Development version (unstable)	main
Previous versions	v1.0.0-beta.5, v1.0.0-beta.4, v1.0.0-beta.3, v1.0.0-beta.2

---

And the readme could contain any other links to docs where you do want people to be reading the latest (e.g. contributing, communication, stability note, maturity classification, etc.). Just avoid lots of links to versioned docs (with the exception of the version table).

[philvarner]

I created a new PR after re-branching here #308

The merge from current dev had a lot of conflicts for so few text changes in this PR, and it is an easier migration process to create a new main branch and merge these changes into it and then switch the default branch than to merge into dev and rename it.