Design development model regarding branching/deployments

[roll]

Overview

As mentioned in #943 the immutable profiles model requires granular versioning so we need to setup a way to work on the next-version (e.g. a branch or using main/tags or etc)

[roll]

@peterdesmet's comment:

---

Agreed. In addition:

We should have a mechanism to separate minor corrections to the website (live immediately) from changes that are part of a new release. The easiest solution I can think of:

• main branch = website. PRs that make quick corrections (e.g. Merge v2-draft and v2 changes in changelog #978) should be merged with this branch.
• upcoming-version branch = all changes for a next version. PRs that affect the standard (e.g. Promote "Metadata in Table Schema" recipe to the specs. #961) should be merged with this branch.

upcoming-version can be brought in sync by merging in main, but the reverse should only be done when we plan to release a new version. That could kick off a bunch of build scripts (preferably a python script triggered by a GitHub Action) that:

• Create generated files
• Update version numbers
• Make a GitHub release