Define what has to be done on a release

[mliebelt]

I need a checklist what has to be done on each release before the release is published to npm. May be it can be completely automated, but first I have to have a complete checklist that allows me not to forget anything on the way to a new build.

Acceptance Criteria

• It is defined how the documentation is done. ✔️ I think that the wiki is most appropriate, because it will be used only in the context of Github. If later the project would be moved to somewhere else, that has to be saved as markdown then (which is easy). The wiki supports things like automatic table of contents, including the navigation.
• The documentation exists and can be accessed by anyone. It has to be public.
• When documenting the steps, I evaluate if those could be improved, and document that by additional issues.
• The documentation has to be good enough to follow it by anyone knowledgeable to get a new release.
• It has to be demonstrated by doing a new release, and taking protocol what was done.

[mliebelt]

I have documented it now in the wiki, and will use that documentation with the next release.

The following should be enhanced in having more details: examples (how to improve them, how to test them); docs (there are some details that are not obvious); npm publication (when to update which part of the configuration in package.json)