Assist with releasing from pull request #3607

You create a release from the PR branch!? Why release that before merging?

Doesn't sound common at all.

As such, I'll have to refuse this request.

• queries for current release versions
• navigates to the "draft release" page with the version populated as a minor increment (user can still edit, so it's just a hint)

See https://github.com/sindresorhus/refined-github/issues/2389#issuecomment-586597292

Release before merging because if the release is broken because of some issue that wasn't picked up in testing, we wouldn't want that in master, where other branches are being made off of for other features. Instead, the release can be rolled back and the branch updated to a good state, proven after release, before being merged into master and potentially spreading the problem further.

It's perhaps a simplified version of gitflow, where the PR (or a rollup) becomes the "release branch", which is prepared for release, released, and then merged back, once it's definitely sure that it's good.

If it's uncommon, perhaps it should become more common. Anyway, I thought it would be useful, but I guess I can just do it myself -- was going to, but then remembered that I use this addon and thought that I can't be the only person who wants this, but apparently I (and my team) are the only ones :shrug:

In retrospect, the order of operations doesn't matter - I could click "merge" and then head off to the releases page. It's the same commit, since it would be fast forwarded. So this is applicable to small iteration gitflow. Not trying to convince anyone to implement it - you clearly don't want to. Just trying to point out that it's not as crazy as you think.

You release something that's not in version control? That flow is quite odd and I can't say I've ever heard of this approach.

Thanks for the explanation, it makes sense to me as I often release betas from PRs:

• https://github.com/vadimdemedes/dom-chef/pull/62#issuecomment-668291533
• https://github.com/fregante/list-github-dir-content/pull/16#issuecomment-553581501

But I don't personally create full releases for it, I just publish to npm and then forget about them forever.

• release to prod from PR branch
• confirm release is good
• create release at GitHub
• merge in PR branch

What's not clear to my is that you first "release to prod", by which I think you mean "deploy to prod", and then create a GitHub Release just before merging

If "release to prod" doesn't actually create a GitHub Release, why not just swap the last 2 points?

  * release to prod from PR branch
  * confirm release is good
+ * merge in PR branch
  * create release at GitHub
- * merge in PR branch

You release something that's not in version control? That flow is quite odd and I can't say I've ever heard of this approach.

how would a branch off of master, which exists at the GitHub remote, not be in version control?

What's not clear to my is that you first "release to prod", by which I think you mean "deploy to prod", and then create a GitHub Release just before merging

correct -- "release to prod" ~ "deploy to prod"

If "release to prod" doesn't actually create a GitHub Release, why not just swap the last 2 points?

  * release to prod from PR branch
  * confirm release is good
+ * merge in PR branch
  * create release at GitHub
- * merge in PR branch

hence my last comment -- the actual order of these two doesn't matter -- I'd still be on the PR page after deploying to prod, or if I chose to merge to master first, I'd still be on the PR page to want to go to releases. We include Octopus links in our PRs -- the build that was successfully tested at staging and signed off by reviewers & QA is the one which is deployed to prod. So for us, the above flow works well, but there's nothing stopping the small inversion you speak of being equally well-served by some PR -> Release flow, as described in the original feature request.

The point isn't so much how we release as that I've had the experience that releases are often made shortly after being on the PR page, so the same usefulness that I get from a Releases tab injected by Refined GitHub elsewhere would be helpful on a PR page. The "extended wishlist" is kind of my "ideal helper", but a lot more work and may not be worth it to be implemented in Refined GitHub. A person can dream though, right? :D

In that case, yes, a "Create release" button appearing right after merging PR would indeed make sense. The details could be discussed further, but as a starting point it would probably be a plain link to releases/new

I think on releases/new you could have all sorts of logic on the content of the release (unlikely to be part of Refined GitHub). We do already have a couple of feature requests regarding new releases: https://github.com/sindresorhus/refined-github/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement+release+creating

I'll opened a more specific issue

100% -- even the inclusion of a link through to releases/new from a PR page would ease the flow a lot.