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.
- Difficult to release (e.g.
aragonOS, other contract-only repos)
- A mix of both (e.g.
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
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
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.