Release Management and Maintenance
Release policy and Versioning
When publishing code (and you should!), marking a specific state of the code is always a good idea. For this, version control platforms like Gitlab or GitHub offer the creation of releases. These indicate a specific commit, containing ideally everything it takes to run the code and/or reproduce the results done with this particular version. When having more than one release of your code, we recommend following Semantic Versioning to number the releases.
This can be done in a very formal way or not, but the idea is this: Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make significant changes to the code (esp. incompatible API changes)
MINOR version when you add functionality, ideally in a backward compatible manner
PATCH version when you make backward compatible bug fixes (also when updating the documentation)
There can be more labels, in particular for pre-release and build metadata, extending the MAJOR.MINOR.PATCH format.
Maintenance plan
As software and technologies continue to advance, maintaining software becomes increasingly important. For instance, your software must be compatible with certain dependencies. Other software may rely on yours. A colleague might have discovered a more efficient way to handle a portion of the code, which could impact the modules or sections you've worked on. New technologies have emerged, capable of managing parts of your code in a more sustainable way. You or your team may need to utilise your code on various hardware types. To address these and numerous other challenges, having a maintenance plan or strategy in place can be valuable.
What the FZJ Software Guidelines say about Release Managment and Maintenance
Class 1 and higher
Releases must be clearly labelled for users, for example by using release numbers. For large software projects, defining a joint release policy is recommended.
Example: To ensure the reproducibility of results and communication, Git “tags” are extremely helpful, especially in combination with a persistent identifier.
Class 3
The institute has arranged for software maintenance and troubleshooting.
Example: The software can either be maintained using your own resources or the community takes over maintenance and troubleshooting. It is also possible to commission a company with this task.