Prereleases Versions on NPM

[boeckMt]

Description

In our current workflow, it can take quite a long time until a new version is published.
Sometimes people need Stuff which is already in the master but we don't have created a new version for it.

---

Our current workflow to create a new version is described in DEVELOPMENT.md

In short:

1. If the master passes all tests and the build works without errors
2. We create a pull request with a release-<version> branch including
   • Update of CHANGELOG.md
   • Set NPM version according to Semantic Versioning
3. If the pull request is merged, push the tag (created from npm version)
4. The tag triggers the github actions Node.js Package

Relevant Package

This feature request is for @dlr-eoc/....

• all @dlr-eoc/

Examples

Prereleases Versions:

• https://semver.npmjs.com/
• https://semver.org/#spec-item-9
• https://medium.com/@mbostock/prereleases-and-npm-e778fc5e2420

Semver uses something like

alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1

We could try to allow pushing tags without the pull request procedure which are in a form like vX.X.X-<identifier>
Angular e.g. uses something like

11.1.0-next.0 < 11.1.0-next.3 < 11.1.0-rc.0 < 11.1.0

A 'Next' Version

• https://docs.npmjs.com/cli/v6/commands/npm-dist-tag#purpose

Furthermore we could tag all this prereleases versions with npm --tag next.

Maybe we can accomplish this all with

• https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-including-branches-and-tags
• https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-ignoring-branches-and-tags
• https://github.saobby.my.eu.orgmunity/t/how-to-create-filter-on-both-tag-and-branch/16936/4

[boeckMt]

@voinSR and @MichaelLangbein what are you thinking about this?

[voinSR]

@boeckMt i think this would be really pragmatic solution. We have already discussed it, frequently we implement some new features during the sprint and then some of our client applications depend on them. Setting the client application to be dependend on master branch may lead to potential problems due to some unexpected updates and breaking changes within the master branch.

[MichaelLangbein]

@boeckMt , @voinSR : completely agree! That would be a really useful thing to have. Releasing a next version shortly before a sprint, for example, would likely mean a lot less effort than a full release. Very pragmatic!