Closed saragerion closed 2 years ago
cc: @alan-churley @dreamorosi @bahrmichael
Thank you Sara.
I am pro automating the release process but still inclined to make the trigger somewhat explicit from one of the maintainers. so I really like the third options you suggested about leveraging releases events.
About the changelog, I would be inclined to leverage the "Releases" area of the GitHub page and use something like release-drafter to create release message upon new release and update a rolling draft every time a PR is merged. The main difference from this system and what you described is that it revolves around PRs instead of Issues but if we commit to being intentional about PR titles and enforce it somehow I don't see issues with it.
This method, also used by the Python version, addresses many of the points described in the Changelog page you linked except the one that states that:
GitHub Releases create a non-portable changelog that can only be displayed to users within the context of GitHub. It's possible to make them look very much like the Keep a Changelog format, but it tends to be a bit more involved. The current version of GitHub releases is also arguably not very discoverable by end-users
I'm not too worried about portability since at the moment we are pretty invested in GitHub as platform. Regarding discoverability I personally don't agree as I tend to look for the Releases section; but this is only my point of view.
In term of actual publishing on the npm registry we can either implement our own workflow based on the Actions documentation or use one of the actions available on the marketplace (this or this); if the available ones fit the bill I'd be inclined to use them so less code to maintain for us.
As discussed during today's standup, if possible, as part of this effort we should streamline the GitHub actions execution. At the moment each PR triggers both on_pr
and on_push
workflows.
Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.
Description of the feature request
Problem statement
For the scope of our first beta release, and consequent ones, when one or more features are merged to main and ready to be published, a release process needs to be in place in order to make the NPM library available to the wider public. Ideally, this process should be as automated as possible to reduce the operational burden of maintainers and contributors who can instead focus on the core business logic of this library.
Summary of the feature
Tasks related to this process can include:
Note that the above should probably be split in multiple issues and/or PR's to reduce the amount of code reviewed at once.
Code examples
Benefits for you and the wider AWS community
Describe alternatives you've considered
Additional context
Related issues, RFCs