Re: Boost downloads and JFrog

From: Sam Darwin (samuel.d.darwin_at_[hidden])
Date: 2024-01-08 13:09:18

> Thanks; then leveraging GitHub releases seems like the best solution to
me. Maybe the only (free) solution we have.

Glen,
While GitHub Releases seems like the best plan, here are a few other
details. JFrog is hosting:
1. development snapshots
2. beta and release-candidates
3. releases

The GitHub Releases paradigm is well designed for 3, and possibly 2.
However it's not designed for "development snapshots" and would really be
forcing that functionality.
- Developers visit the GitHub releases page, and hopefully the top listing
would be the latest actual release. If the main listing is a 'develop'
snapshot and a 'master' snapshot, that could be confusing, since it isn't
an official release.
- A release is tied to a git tag.  While tags can be changed, they are
usually expected to be immutable. Publishing a dev snapshot multiple times
per day would constantly re-write the so-called 'snapshot' git tag.  Or
fill up the page with 1000 releases. No.

An idea could be to publish official releases on GitHub, and continue to
host development snapshots on JFrog.

Bandwidth to the snapshots is probably low enough to mean that a CDN isn't
necessary, however if the pricing is favorable, certainly add the CDN.
Directly assume billing for both JFrog and the CDN, so they wouldn't shut
them down.

Even the official releases could continue to be uploaded to JFrog, as a
backup storage location, if authentication is enabled on those specific
files. With authentication, internal scripts would have access, while the
general public would be prevented from downloading releases from JFrog in
certain folders.

https://github.com/boostorg/release-tools already has support for GitHub
Releases from years ago. Should be reviewed.

However, this goes back to the topic about development snapshots. I would
not recommend enabling that for daily snapshots. Only using
github_releases.py, every 3-4 months, for the official releases.

Notice the GitHub CLI 'gh'  'gh release' sub-command.  It makes sense to
leverage the gh cli as much as possible.  the project has 34k stars, and
7000 commits.