vrtbl/passerine

New Branch & Github rules

rishiosaur opened this issue · 3 comments

rishiosaur commented

For the next few releases, I'd like to standardize our DevOps and release procedures (this is sort of related to #10, but a little bit more general; this is more meant to discuss the way that branches are laid out).

Additionally, I'd like to talk about what contributing guidelines, CoC, and PR/issue templates should look like.

slightknack commented

Sounds great!

Let's see - so as we discussed on Discord, I think we were looking towards some form of rolling-release schedule, similar to Rust's:

  • Features are worked on in forks, preferably in their own branches. Once implemented, merged into master and hidden behind feature flags.
  • The master branch is compiled weekly.
  • The beta branch is pulled from the master branch every quarter, new features included. During this period features should be stabilized if needed.
  • The release branch is pulled from the beta branch at the end of every quarter.

Of course this is just one potential git flow and time timescales (weeks, quarters) can be adjusted.

So as for contributing guidelines and CoC, they're kinda just mashed together in CONTRIBUTING.md atm. Ideally we'd separate this out, and use some predefined CoC, like the Contributor's Covenant or something.

What are your thoughts on PR/Issue templates?

slightknack commented

So currently, we have two primary branches:

  • master, which must always build. Releases are periodically published from this branch
  • dev, which doesn't have to always build, but must be green before merging into master. This branch is always the target of the next minor release.

If you're implementing a feature for the next minor release, merge the PR against dev. If this is a bug fix or something that could be included right now, no issues raised, merge the PR against master.

slightknack commented

Issue seems stale and we seem to have found a git flow that works, so I'm closing this issue.