Versioning Proposal

[dsweber2]

This implements the github actions to make 0.<increment on release>.<increment on PR> usable by making the dev docs on the dev branch, and the release docs on the main branch. Along with this, I suggest that we make main the default branch, so that people have to opt-in to the dev version, rather than opt-out of it.

It also introduces a semver check to make sure that any PR includes a bump to the semantic version. Hypothetically this should fail on this PR for the first commit, to be fixed after confirming this (if only there were a way to test gh actions).

[nmdefries]

Drive by comment: Thanks for adding these actions!

I suggest that we make main the default branch

Doesn't this cause problems with PRs? e.g. opening a PR will default to being against main and could lead to accidentally merging changes into main.

semver check to make sure that any PR includes a bump to the semantic version

Propose having an action to bump the version (from dev) on PR merge to dev. I've already run into the problem where my PR and another bumped the version to the same number, so I then had to re-bump. This also causes the changelog to be hard to maintain for the same reason.

[dsweber2]

Ok, so I think I got the auto-version bumper working (hard to tell without merging this, but it was successfully bumping the version every commit before I switched that to only happen on dev and not every branch).

It's also set to auto-generate a tag for minor and major releases, and to do minor releases on any commit on main, and major releases on a release branch; we may want to mess with the settings there and make that one manual.

[dsweber2]

I suggest that we make main the default branch

Doesn't this cause problems with PRs? e.g. opening a PR will default to being against main and could lead to accidentally merging changes into main.

I guess it depends on if we're prioritizing user-experience, so that by default people get a more stable version, or dev experience, so we don't have to do some git history magic if we mess up. Doesn't look like github has a way to set a PR-only default branch, unfortunately. Just a thought while I was working on things that distinguish a "release" before we're on CRAN.

[dshemetov]

We can get a good dev experience and a good user experience by keeping dev the default branch, but recommend users install from the main tag (which we already do in Getting Started devtools::install_github("cmu-delphi/epiprocess", ref = "main")).

[dshemetov]

Propose having an action to bump the version (from dev) on PR merge to dev. I've already run into the problem where my PR and another bumped the version to the same number, so I then had to re-bump. This also causes the changelog to be hard to maintain for the same reason.

@nmdefries @dsweber2 this is addressed now right (we're only bumping on merge to dev)?

[dshemetov]

Can we / should we automate merging back to dev from main? That will probably trigger a version bump in dev, but I'm fine with always starting on x.y.1.

[dsweber2]

Propose having an action to bump the version (from dev) on PR merge to dev

Is addressed by the fact that the version bump applies at merge time on the dev branch, rather than in the PR. Which kind of bump depends on whether its on dev or main.

Can we / should we automate merging back to dev from main?

Oh, yeah this is probably a good idea; I guess we can just copy the action from a different repo?

[dshemetov]

There's this. Having to manually merge the sync PR is minorly annoying, but figuring out how to get GH Actions to auto merge from main to dev might be even more annoying.

[nmdefries]

issue: should auto-tag someone so the PR doesn't get lost. Example.

Or merge automatically.

[nmdefries]

suggestion (nonblocking): could be useful to have a "Release" workflow (and button) to merge dev to main.

[dsweber2]

oh hey, that's handy. Given that all that happens is a version bump I think auto-merge should be the better option.

[dsweber2]

Not sure the release workflow is worth the effort to actually get it set up, given that that one is specific to python code, but good to know it exists

[nmdefries]

Agree about maybe not worth the effort, but that release workflow is for R -- python is just used to do the bumping. (forecast-eval doesn't have any python code.)

[nmdefries]

Looks good!