Set branch strategy

[ryan-jacobs]

I noticed that there is a "development" branch available, but it appears that most work is being committed directly to the "main" branch. It might be worth thinking through:

• What branch strategy is best for the project (GitFlow, Trunk, etc.)? Most of these will leverage some form of feature branches for non-merge commits.
• What will be the purpose of the "development" branch?
• What should be the "default" branch (the one that appears by default on the project page and the one then people clone by default)?

For other CRL projects we often use a loose GitFlow strategy and use a develop branch as both the default branch and as a place for integration testing (manual and automated). This is a place where multiple features are merged into one place upon completion, but may not yet represent a release-ready product. This reserves the main branch for just release management (e.g. merge to main to mark a stable point that can be a release). While this has served us well elsewhere, and may provide a case for consideration, each project has its own needs and it will be best for validator maintainers (@nflorin, @AndyElliottCRL) to set the strategy here.

[nflorin]

I've been thinking about it and using "development" as the default branch and "main" just for releases makes sense to me. When we were thinking about the Validator as a more ad hoc project the single "main" branch made sense, but now that we are thinking in terms of releases it's no longer appropriate.

My plan right now is to merge everything into "main", delete "development", and then rename "main" to "development". Then for a release create "main" (and generate the release). Future work will take place in feature/bugfix branches that would then be merged into "development".