Better Release Workflow

[dahlbyk]

Alright, now that 1.1.0 is out the door I would love for this to be the last manual release.

Since @bergmeister proposed #698 2½ years ago, how has the state-of-the-art evolved in terms of easily and consistently building and releasing PS modules (or any versioned software, really - I'm an "always deploy main" web guy)?

• As of #878 we have replaced Travis and AppVeyor
• I would love to be able to tag a Release in GH and have it automatically publish to PSGallery
  • And Chocolatey? #772
  • And WinGet? #891
• Updating CHANGELOG.md is always a chore
  • Anyone have or know of a pattern they like for automating release notes?
  • Should what's been in CHANGELOG migrate to the GitHub Release, maybe with a vNext Release draft opened to collect changes as they arrive?
• How do we retain a good workflow for the various ways people install posh-git?
  • Local clone in random folder; Import-Module ~/path/to/clone/of/posh-git/posh-git.psd1
  • Clone into a path in $env:PSModulePath
  • Install module for current user
  • Install module for all users
  • Import clone or whatever even if a different version is installed for all users (https://github.com/git-for-windows/git/issues/1384)
  • Chocolatey?
  • WinGet?

[manmartgarc]

Happy to spend some time on this in the near future

[Nixxen]

• Updating CHANGELOG.md is always a chore

  • Anyone have or know of a pattern they like for automating release notes?

Disclaimer: I have not worked with automated release notes, but have heard it mentioned in conversations related to DevOps. I figured I'd chime in with what I've found in the hopes that it is helpful for further work. From what I remember from these conversations, the key has been flags in the git commits that trigger either changelog updates or if no tag is found, the updater/action ignored the commit and passes it as a "silent" update. Versioning is updated automatically, and "in-between" commits get flagged as such.

I did a cursory search and found several mentions of such systems. One example of something that looks promising is git-cCliff. Examples of individual release changelogs can be seen on their releases page, or the entire history on their entire changelog.

If you compare the commit history with the changelogs you can see which tags they have decided to include in their releases (the project allows for any of the tags in their readme, but only some are included due to their preferences).