Proposal: Multiple Production Branches

[U8NWXD]

In #192 it became clear that it would be nice for us to be able to create v2 releases that break v1 functionality without pushing those releases out to all users and breaking their code. Here's how we could do this:

Git Workflow

• Create a develop-v1 branch from the current master. This is where we'll put any bug fixes needed for the v1 version of Vivarium Core
• Our development moving forward would be on develop-v2.
• Like we do currently, we'll use a git tag to label each release.

Versioning and PyPI Workflow

• Our v2 releases will at first be pre-releases as defined by PEP-0440. For example, 2.0.0a1 for the first alpha release or 2.0.0b3 for the third beta release. pip should not install any of these pre-releases when a user runs pip install vivarium-core.
  • PEP-0440 describes some alternative ways to format the version numbers. For example, instead of 2.0.0a1, we could use 2.0.0-alpha1, 2.0.0-alpha.1, 2.0.0-alpha-1, etc.

Questions to Answer

• [ ] What do we want to call our main development branch (i.e. what we currently call master)? There's a certain symmetry to calling it develop-v2, but then the name of our main branch would change each time we start a new major release (e.g. when we start developing v3).
• [ ] How should we format our version numbers (examples above, more details in the PEP)?
• [ ] When do we want to use alpha and beta releases? Should we just pick one? Note that by convention, alpha releases are for internal testing, while beta releases are for testing by outside users. We may not need that level of granularity, however.