Maintenance: release process

[saragerion]

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:

• Github workflow triggered any time a change is pushed to the main branch - that will validate, through different tests, that the code is production ready. Why similar automated tests might already have been performed in the PR branches, I would advice that we protect the main branch again any changes added.
• Before the code is released, release notes should be added in the Changelog file(s). See this website for reference. It would be nice to have but not paramount for the beta release if we could automate this to avoid losing so much time understanding what is gonna be released and what is still not merged. This can be achieved by looking for example at the issues placed in the "Done but not yet released" column of our Github Project:

- Github workflow triggered any time a new [release](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#release) is created. Release steps may include (but not limited to): compile, lint, audit, test, publish the code.

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

[saragerion]

cc: @alan-churley @dreamorosi @bahrmichael

[dreamorosi]

Thank you Sara.

General

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.

Changelog

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.

Publishing

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.

[dreamorosi]

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.