Today the release process is not a real release process. It is more a continuous release + LTS (long term support) maintenance of one or two versions.
We develop anything on as-needed (or better as-paid) basis.
Positives
- It kind of works – we have what is really needed
- We save time on planning as we do not plan too much
- We save time on writing release notes as we publish GIT changelog and pretend it is release notes
- We ship very quickly as we do not care about documenting everything, the one who needed the feature has it and knows how to use it
Downsides
- There are some strategic developments that no-one knows when we do them. We finally do it but sometimes it takes years and it is not quite clear when it will be ready.
- Partners and customers always ask about our roadmap but we are not able to clearly present it. It is also important for new potential customers as that is what they study when considering ORIGAM.
- New developers would like to know what they are going to do. A lack of a roadmap also makes this hard to say.
- A GIT changelog is not good enough as release notes. Sometimes it is too detailed (small features split within multiple commits) and sometimes too simple (major features with lots of detail functionality – single merge). It also does not clearly state what are the breaking changes, migration paths, etc.
- New features are not documented well or not at all and one might get an idea from the topics here but often the requirement is not described in detail anyway. Documentation is not good and everybody says it.
Proposals
Introducing a release process could solve these issues. We would organise developments into e.g. sprints that would have a clear structure:
- Planning and picking from a backlog – For the next sprint we would only pick issues/features which would be previously described and discussed here. Especially features, I think we do well with fixing bugs. The backlog would probably arise from some major topics (e.g. model storage format or workflow engine functionality) or single feature requests.
- Versioning strategy – Today we think about versions always as stable builds vs. master build. The new way would be more like a new version (e.g. 2022.5) every month, which, if buggy, would be replaced by the next version (e.g. 2022.6). Neither of those would be considered long term support. That would be e.g. 2022.1 which we would hot fix for the rest of the year. We would not hot fix the continuously released version.
- Documentation as part of pull requests – a feature should not be accepted (maybe even merged) without a release notes entry and without a proper documentation of it. I guess this is the only way how to make the documentation up to date. It might not be the developer who developed the feature who should document it (someone responsible for writing the docs could cooperate) but it should be part of it.
- Tests – as we now also have automated end-to-end tests, we should consider acceptance criteria for pull requests to also contain tests. At least they should be part of the release process in some way.