Release v3.8.0

[levb]

@kozlovic This PR is to the release branch. Once merged, I will create a PR against main that would cherry-pick these changes, and update main's version to 3.9.0-beta.

I am also updating the release instructions page now. Will send a PR once I finish the release and the updates.

• [x] Update the doc branch gh-pages
• [x] GitHub release
• [ ] Brew package
• [x] Update main

[kozlovic]

I am confused. Since you are going to do a release, there is no need to have a release-v3.8 branch (at this time). I would have a PR done against main, and when merged into main, then you can release from main.

Where we would need a release-v3.8 branch, is only if we have to issue a patch release, say 3.8.1 before we can release 3.9.0. So although likely, I would defer creating release branches (that will need to exist forever) until we have to.

[kozlovic]

To be clear, unless you need to do a v3.8.1 release before a v3.9.0, there is no need to create the v3.8 branch and cherry-pick commits as they come. You can do it, if you think that it is easier process and avoid having to do possibly a bunch of them at once, but I guess it depends the projects. In the NATS Server, surely this makes sense since there are many commits/fixes in between releases. But for this repo, not so sure, it depends. There are some time where there is a bit of activity and I could see creating the branch ahead of time makes sense, but lately it has been pretty calm. But you chose. I will LGTM the PR in case you want to proceed with the release branch.

[levb]

@kozlovic I understand, and indeed was first going to release off main and defer creating a 3.8 branch until the first patch, but 1/5 I didn't like it. I'd rather consistently always create release branches (for minor releases) and cherry-picking into them. FWIW, I can also then make the main "consistent", e.g. its README points at a good release, etc.

The cherry-pick PR to main (after the release is made) will update it to 3.9.

[kozlovic]

Even if you had created the v3.8 branch before a need for it, I would still have created out of main, that is, I would have created a PR for the release against main, when merged to main, I would then have created the v3.8 branch out of main for later use. Then I would have updated main's version to point to 3.9.0-beta. At this point in time, main does not have commits from the 3.8 release and still refers to 3.7.0 release as the latest. This is - in my view - not the right process.

[levb]

@kozlovic I am having brew issues, any advice? (it passed with --dry-run)

still refers to 3.7.0 release as the latest... not the right process

Ack. Will fix main momentarily. In the future will create the v3.X.0 tag and release first, off main, and then checkout -b release_v... from it.

[kozlovic]

Re brew: Not really. Make sure you have brew updated. Note that the brew community usually will update the formula if you don't get to it first. They are pretty fast at updating it so don't worry too much about it.