Hmm, good points.
I’m rethinking the prior branching strategy, as a prescriptive “one-size-fits-all” won’t work well.
I see three different types of repos we maintain:
- Immediately releasable (e.g.
aragon-cli,aragon.js,aragon/aragon) - Difficult to release (e.g.
aragonOS, other contract-only repos) - A mix of both (e.g.
aragon-apps)
Immediately releasable repos should just follow simple git practices. One master branch, and any hotfixes can be made against both master and the target version. An example of this would be on aragon-cli: if we had large features added to master that we weren’t confident in, but still needed a hotfix (like pinning a dependency’s versions), we would make a PR to pin it, and then cherry-pick that commit to another tagged commit to release a hotfix version (with a git tag). In more difficult cases, two PRs may be necessary to patch both the master repo as well as the old tag.
Difficult to release repos should follow a master and next (or dev) strategy, where master contains the latest stable version, and next contains the current HEAD of work. The default branch should be next. This is particularly useful to signify that master is of strong quality (e.g. only audited code), but we could also switch around the branches (e.g. an audited branch that gets fast-forwarded every time master is audited).
Repos with a mix of both should follow a master and next strategy, but with the default branch being master. All difficult to deploy changes should be against next, and should not impact other code, to keep merge conflicts simple. All deployable changes should be against master, such that master is always deployable. When next is ready, it should be merged against master alongside any required updates (e.g. frontend) for those breaking changes.
I agree that keeping the default branch as master is intuitive for most developers.
At this particular point in time, I’m of the strong opinion that we should only support the latest versions of packages, and mark when a package is not compatible with a previous version (e.g. aragon.js to aragonOS). We can revisit this when the ecosystem grows larger, and we have breaking releases which are more onerous for developers to upgrade.
