For each new release create a Github release

[jonathanwiesel]

Currently the Github feature of releases is not being leveraged, therefore is difficult to track and determine which version is which and it includes, both at the source, binary and feature level.

Also (and the real reason I posted this), leveraging of releases would also enable the community to watch the Releases event and therefore be notified if they wanted for every new release 😄

[jonathanwiesel]

Well, to be fair, the real releases are being generated (partially, not all) in the salesforce/cli repo so the relationship of the source to its corresponding version is indeed captured there, however, since the release notes are not maintained there then my real point still stands regarding enabling the community to be notified about when new releases (with their corresponding releases notes) are shipped.

[cristiand391]

every CLI version has a GH release in salesforcecli/cli, a coworker noticed GH is missing releases in some repos in the web UI, hope that gets fixed soon.

gh release list --repo salesforcecli/cli
TITLE        TYPE         TAG NAME     PUBLISHED
2.37.1       Latest       2.37.1       about 1 hour ago
2.36.8                    2.36.8       about 20 hours ago
2.37.0                    2.37.0       about 1 day ago
2.36.7                    2.36.7       about 2 days ago
2.36.6                    2.36.6       about 3 days ago
2.36.5                    2.36.5       about 4 days ago
2.36.4                    2.36.4       about 5 days ago
2.36.3                    2.36.3       about 6 days ago
2.36.2                    2.36.2       about 6 days ago
2.36.1                    2.36.1       about 7 days ago
2.36.0                    2.36.0       about 8 days ago
2.35.6                    2.35.6       about 9 days ago
2.35.5                    2.35.5       about 10 days ago

about the release notes not being in the same repo, this process isn't automated but maybe a link to the release notes file could help.
Sometimes we also update the release notes (patching RC or latest) so you would need some sync automation or GH releases notes would be stale. @iowillhoit might have more details, I'm don't recall what were the constrains when we discussed this.

[iowillhoit]

Hey @jonathanwiesel,
I'll do my best to explain our release process and you can let me know if you have an idea for how we could be displaying the release information better. Note: Like Cristian said, the GitHub UI seems to currently be having issues rendering Releases, they do exist.

First of all, our release process for the CLI is completely hands-off. Here are the basics of how it works:

Plugins and Libraries

• We use Conventional Commits to drive our semantic versioning.
  • If a PR is merged with a fix: commit, we bump the patch. With a feat: commit, it bumps minor, etc
  • Once a PR is merged a new release of the plugin/library is created.
  • If you look at the Release of a plugin/library. The conventional-changelog-action generates the body based on the commits. Here is an example from plugin-auth@1.50 that shows both "fixes" and "feats".
• Dependabot runs multiple times per week bumping dependencies and auto-merging them if they are green.

The Salesforce CLI

• Every night a nightly build is created. A PR is created that collects and updates the latest version of the dependencies that we have "pinned" in our package.json.
• If all the tests pass, the PR is auto-merged.
• A Github release is created (example)
• That triggers a new release of the CLI (example)
• On Wednesdays (mid-day), we simply run two promotions.
  • We promote latest-rc to latest
  • and then we promote nightly to latest-rc
• We merge the Release Note PRs written up by our Tech Writer to reflect that week's changes.
• Wednesday night, the next nightly is built with a new minor version.
• Rinse, repeat.

With that information, here are few things to note:

• If you are curious what changes went into a nightly, the PRs can be seen here
• Try the sf whatsnew command. It looks up your installed version, finds the corresponding Release Notes, and prints them to your terminal. You can also pass a few flags, run sf whatsnew --help for more.
  • If you have the CLI installed with the OS specific installers, sf whatsnew runs as a post-update hook.
  • This used to work with npm installs, but npm now swallows all install/update output unless you pass the --foreground-scripts flag
• It is unlikely that we will ever write Release Notes for every nightly. However, one thing I could see being useful would be to try to include the plugin/library changes in the CLI Github Release body here. For example, the body could say: salesforce/plugin-org bumped from 1.2.3 to 1.2.4 (see: link_to_that_release)

Let me know if this answers any confusion or if you have any ideas on what could be improved. Thanks!

[jonathanwiesel]

Thanks a lot for the quick feedback and for the detailed explanation @iowillhoit and @cristiand391

I agree that having release notes for every nightly would not be ideal for many reasons (not to mention the effort behind it vs the use it could have).

Indeed seems that the UI is having some issues showing releases, hopefully it gets fixed soon (since potentially it could also impact the ability to notify watchers when new ones are published).

I do think that having at least a link in the body of the release would make it easier for watchers to have better visibility on the ongoing changes that are happening and when, regardless of their final installation.

Cheers

[iowillhoit]

You are welcome @jonathanwiesel!
When you say "a link in the body of the release", do you mean a link to the Release Notes (https://github.com/forcedotcom/cli/tree/main/releasenotes) from the body of every Salesforce CLI Github Release (for example)?

That would be a pretty quick change to connect those two resources.

[jonathanwiesel]

@iowillhoit as long as there are in fact release notes for a particular release I think that would be more than enough (if there aren't it could be misleading).

What concerns me is that I'm not sure how feasible is to easily identify if a release would have release notes in order to include the link.

Best case scenario, is feasible and could even automatically link to the appropriate heading in the release notes (considering is a single file with all versions, although since many releases have other annotations like stable, rc and so on I think I would be asking dor too much).

Worst case scenario, is not feasible and all releases will point to the exact same release notes file regardless of being any release notes for it at all (not ideal, but is somethijg to bridge the gap)

[mshanemc]

followup: we opened a github support ticket and they reindexed all of our repos so now the releases show up again.

We probably can't do RN for every nightly https://github.com/salesforcecli/cli/releases

One of those every week becomes RC. The probably with linking is how we have the RN headings in markdown.
For example, on https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md#2387-april-24-2024-stable-rc the link changes once it's no longer stable-rc.

And if we do an RC patch, we end.up changing the 2387 part (ex: we'd change it to 2388 to reflect whatever the patch does, but then your 2387 link would be broken.

I prefer to let the manually created RN be where they've always been. We've considered doing something of a "changelog rollup" where changelogs from plugins and library changes between nightlies get aggregated into a CLI-level changelog. Thoughts on that approach?