Semantic Versioning (semver) is the most accepted and used way to add numbers to software versions.
It is a way of communicating impact of changes in the software on users.
Very often package managers depend on
semver and will not work as expected otherwise.
Use github releases.
Change log is a way to communicate notable changes in release to the users and contributors. Every release should have relevant entry in change log.
One command install
This applies to software which is distributed as package or library that will be used by other software or from within other language. Should be implemented when there are (going to be) first users of the software, so that they can use default package managers.
Package in package manager
This is a way to publish the package.
Discuss release cycle with coordinator
Release cycles will depend on the project specifics, but in general we encourage quick agile development and therefore frequent releases.
Release quick-scan by other engineer
A check by a fellow engineer to see if the documentation is understandable? can the software be installed? etc.
Think of it as a kind of code review but with focus on mechanics, not code. The reviewer should check if: (i) there is easily visible or findable documentation, (ii) download works, (iii) there are instructions on how to (iv) install and (v) start using software, some of the things in this scan could be automated with continuous integration.
Create a DOI for each release see Publishing results chapter.
news item on site / annual report, etc.
News item should be made for at least first stable and subsequent major releases.