Light-client: Create a release.md to document the release steps

[nephix]

Description

As a dev I want to know the steps on how to release a new SDK version

Acceptance criteria

• Manual steps are written down somewhere (preferably before we start the automating) so anyone can do releases manually if necessary

Tasks

• [ ] Figure out what the automated steps are
• [ ] Decide which account to use for publishing
• [ ] Investigate how automatable it is to push new releases (e.g. when a new tag is created) to github and npm including change log etc -> see #38

[kelsos]

@nephix automating should be easy (I already did something for github releases and PyPI for the WebUI), we just need a bot account that will be used for the releases. And @andrevmatos to create a basic manual release documentation.

[andrevmatos]

SDK release is very simple:

• bump version in SDK (and possibly also in dApp) package.json
• tag
• npm publish

For this, we need to check on which user to keep the raiden-ts npm package. Ideally, it be an organization (we already have one for @raiden_network), but afaics, this requires scoped package installation & import (import { Raiden } from "@raiden_network/raiden-ts";), which is quite ugly.
We must check if we can have a non-scoped package in an organization, so we can move package there, and get a bot user to do the publishing to it on tag. If not possible, maybe create API keys to publish to a individual account instead of the organization one.

Additionally, it seems GitHub added functionality for its own npm repository. It'd be interesting to release to it as well, besides npmjs.com

[kelsos]

@christianbrb who should manage/create the npm account on the organization level? would that be @nlsdfnbch?

[nephix]

SDK release is very simple:

• bump version in SDK (and possibly also in dApp) package.json
• tag
• npm publish

Writing release notes, picking a release name, not sure what else needs to be added? I think having it somewhere written down and explained so a 5 year old could do a release wouldn't hurt.

That way, everyone can do a release in the future, even if something needs to be hotfixed and everyone is on holiday or ill.

[andrevmatos]

The steps I wrote are for npm release of the sdk, not including the full release process steps (github release). But yes, it is useful to have everything documented somewhere too. Just wrote this part because is the one that can/should be automated. The github release can't.

[kelsos]

So in the WebUI we have a RELEASE.md that describes the steps required in the release process. Maybe it would make sense to create this kind of documentation for the process.

[andrevmatos]

Ok, we got raiden-ts package to continue to be an unscoped package now on the raiden_network org: https://www.npmjs.com/org/raiden_network?tab=packages
Now, the developers team members can do what I described above. It's just a matter of bumping and publishing. We should automate that on CI.

[andrevmatos]

So, the release steps should look something like:

• Create a bump PR
  
  
  
  • Possibly have a bot to do this, and also create and push the tag after the PR tests passes and is merged
  
  
• Have a CI step to, on tag on master, publish to the npmjs repo
• Go to project's release page on GH, create a new draft release and point it to the tag above
• Draft the release, copy the changelog, get a review on it, and publish the release