Use the GitHub releases feature

[victorlin]

We use GitHub releases for Auspice and should do so for Augur. It was used in the past but stopped with version 6.3.0, I suspect because of tedious manual work. Once #904 is merged, GitHub releases can be created automatically with a bit of extra scripting using gh release create.

There's 2 ways to approach this. I favor the 2nd, but would like to hear other opinions.

1. Start with the next version

We can ignore the previously missed tags and just start creating releases with the next version (e.g. 15.0.2).

• Pro: Easy.
• Con: The release page will be inaccurate. Augur did not jump from 6.3.0 to 15.0.2.

2. Retroactively create releases for all previous tags

This would be for 6.4.0 to the latest tag whenever we decide to do this. (with 15.0.1 it is 39 releases)

• Pro: This will make the release page mostly accurate, besides the release date being the same for all the releases we create retroactively.
• Con: This may be a one-time tedious task to get the release notes together, but gh release create should help make things easier.

[corneliusroemer]

I'd love to just have releases immediately - we could just add a note to the first release since 6.3.0 that releases in the meantime have been missed.

I don't think the con is worse not using the release tab immediately. What do you think @victorlin? Most recent is the most important thing anyways. If anything, we could add a few releases manually so there's a bit of context for the last few months. I don't think anyone cares for v11 for example anymore.

[tsibley]

Stepping back a bit here, what's the goal of using GitHub Releases? Is it primarily to

1. Disseminate release information/announcements, or
2. Distribute release artifacts?

If (1), great. This makes sense to me.

If (2), it's not clear to me who the expected audience is for this. Who or what would be downloading Augur release artifacts from GitHub instead of from PyPI or Conda (which derives from PyPI)?

(Context is that I was thinking about this again in nextstrain/docker-base#44 (comment)).

[tsibley]

Looking at Auspice's use of GitHub Releases, it appears that the only release assets are source code snapshots, not NPM package artifacts. Is this the same use we'd expect with Augur? Is it potentially confusing that the GitHub Releases don't include the preferred form for installation (wheels or sdists)?

[victorlin]

@tsibley I see it as mostly (1). Should be easy to do (2) with GitHub Actions since dist/ is already uploaded as a release workflow artifact. But I agree, not sure who actually goes to GitHub Release pages to download when there is PyPI/NPM, so probably not much benefit there.

[victorlin]

@corneliusroemer right, just having the latest release shown in the sidebar would be the main benefit. With a bit of scripting in release.yaml which I'll look into, we can easily start with the next version and retroactively create older releases if we ever want to later.

[corneliusroemer]

Can we just start using releases immediately and not worry about the past, I feel like perfect is the enemy of the good here.
It's hard to figure out what the latest release is at the moment - one needs to check out tags - rather than just seeing releases immediately.

Re @tsibley's point, I think releases are mostly about communication, notification, so (1), not really to distribute.

At least that's how I use it and how others seem to use it, too?

[victorlin]

Yes we should start using Releases without worrying about older ones. #957 is there but needs some work. @tsibley has done the same over at nextstrain/cli#186. I plan to review that then incorporate the good stuff into #957.