Orb Branch Workflow and Release Procedure

1. The source of truth for the version is the root VERSION file, which is semantic versioning plus an optional suffix.
2. There are three special branches: main, develop, and production. main gets stable/self-host merges, develop is continuous integration branch for feature development with continuous deployment to Staging environment, and production contains production orb.live releases.
3. For in-repo development (not forks), development happens in ephemeral feature/* branches, for example feature/FEATURE-NAME or feature/ISSUE-ID, which should be branched from develop
4. For extra-repo development (forks), development can happen directly in develop branch of the fork
5. Upon feature completion, a PR is created against the develop branch; CI will integrate, test, and build packages. If CI is green and the PR is approved, the change lands into develop branch.
6. Pushes to develop branch will build and push packages with the -develop suffix on the version, and develop, VERSION-develop and VERSION-develop-HASH tags on docker hub.
7. On stable release, develop is merged to main. Once in main, the version should be updated to remove any version suffix.
8. Update version notice and download links on getorb.io