Create production branch

[twiecki]

We should have a separate "prod" branch from which the model runs so that master can be a bit more stable.

Alternatively, we could have releases and production only ever uses the most recent version which is known to be stable.

[k-sys]

I've been going back and forth on this in my mind – any maybe there's no "right" answer, but @mikeyk might have a feeling...

My principles here would be:

• Allow for fast "bleeding edge" development without worrying about introducing issues into production
• If someone clones the repo and they're on master, we should generally assume they want to see the same results that are in production. I'm wary of using master as the development branch because it's far less likely to be thoroughly tested/vetted and if someone wants to see our best/stable I think that should be on master rather than telling people "oh hey, checkout this stable branch that's hard to find"

So my proposal is that we use master as our production branch – it's the latest stable branch and doesn't change wildly day to day. For development, we have a development branch on the side that contributors can merge into more freely.

Note this is different than, say, pymc3 where the git repo's default is latest (unstable). Since people are not installing this via pip or conda it becomes more difficult to pin a version so master should be the version we want people using locally, and thus it should be more stable.

[mikeyk]

I’m generally a fan of the git-flow ( https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow ) workflow. We don’t need to use the full git-flow toolkit or even all concepts, but at its core: - master (stable) - develop (main dev branch; where PRs fork off of and land) - PRs happen off of develop - Merge to master on release OPTIONAL: RELEASE BRANCHES - branch a release branch off of development when we’re doing a release - bleeding edge continues on develop branch and final polish can go into release branch - IMO this part is overkill for this project due to # of committers Now the one wrinkle here is that if we continue to do data hotfixes in code, we need to make sure we cherry-pick them over from master to develop. Or, we could have the data hotfixes in a separate repo that just has one continuous master branch that gets committed to with every data fix. My suggestion (simplest mod from where we are today) is: 1) move to master + develop branches with PRs off of develop and merges when model is stable 2) continue to hotfix master with data fixes and cherry-pick to develop 3) mid-term, continue to work on ways of handling data weirdness that doesn’t require manual intervention

…

On Sun, Jul 5 2020 at 8:35 PM, KS < ***@***.*** > wrote: I've been going back and forth on this in my mind – any maybe there's no "right" answer, but @mikeyk ( https://github.com/mikeyk ) might have a feeling... My principles here would be: * Allow for fast "bleeding edge" development without worrying about introducing issues into production * If someone clones the repo and they're on master, we should generally assume they want to see the same results that are in production. I'm wary of using master as the development branch because it's far less likely to be thoroughly tested/vetted and if someone wants to see our best/stable I think that should be on master rather than telling people "oh hey, checkout this stable branch that's hard to find" So my proposal is that we use master as our production branch – it's the latest stable branch and doesn't change wildly day to day. For development, we have a development branch on the side that contributors can merge into more freely. Note this is different than, say, pymc3 where the git repo's default is latest (unstable). Since people are not installing this via pip or conda it becomes more difficult to pin a version so master should be the version we want people using locally, and thus it should be more stable. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( #14 (comment) ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAAFF4I56UCOFBHVTHLMSELR2FA7HANCNFSM4OPS3X7A ).