This can be done from develop or seperate release branches (before merging to develop)
- Change the version-number in accordance with the magnitude of change.
- If its not a
@latest
release, the type should be "dashed", for example;0.0.0-beta
or0.0.0-dev.20210101
. - We try to follow semver but are holding back major v1 until we feel its ready.
- If its not a
- Update the changelog for your library in
CHANGELOG.md
.- Follow the guide in the changelog file.
- Add a release on github with the changes you added in
CHANGELOG.md
.- Name the release in accordance with package name and version, for example;
[email protected]
- Name the release in accordance with package name and version, for example;
- Find the corresponding workflow for your library, usually prepended with "Publish <LIBRARY NAME>".
- "Run workflow" and decide if input values need to be changed.
- Storybok slot: If present, choose which environment Storybook should be updated.
- Leave this input empty for deployment to production
- NPM tag: Choose which tag to apply to the published package
- Choose
latest
for production release
- Choose
- Storybok slot: If present, choose which environment Storybook should be updated.
⚠️ Check "Publish eds-<LIBRARY NAME> to npm" step to verify the package was actually published. If an existing version exists on npmjs.org, the package will not be published, but this step will still pass.