Contributor's Guide : Release Workflow : Explanation of how releases are compiled and how tagging is used #1280
Description
The Contributor's Guide has a description of artifacts and common workflows around the development of the application and its plugins. While the overall release process of the application is left implicit there, we can find a series of tags next to the repository and a separate documentation page of how to release a plugin into the plugin gallery.
As a Software engineer in the PKP ecosystem, I need a written description about conventions and practices used to build and release the software, in so I am rendered more capable to contribute with less friction.
As a systems engineer taking and deploying components from the PKP ecosystem, I need a conventional way to reproduce Software artifacts, in order to ensure reproducibility and deterministic execution of code paths.
Related to this, due to terminology used which is local to the PKP development community, it is quite hard to find the changelog which informs about breaking changes and added features. A curious reader will find their way around to the Release Notebooks, but the section in the Contributor's guide doesn't link there and the common term Changelog is nowhere to be found on that page nor the other(s), neither with search.
Explicitly stating the practices used to build releases increases the trust in the procedure and allows others to replicate it more easily, inviting for more collaboration. In addition, making links between content explicit can render it more accessible/navigable and reusing conventional language lowers the entry barrier for non-native speakers by sacrificing semantic specificity for syntactic simplicity.
Ultimately, the Contributor's guide holds information about the branching convention, but no obvious explanation how tags are chosen and published plus subsequently compiled into a release. Whereas on the other hand the procedure to Release a Plugin has mentions of versions, but no reference to tagging, branches or a typical development-release-workflow.
Could we coordinate a little around updating the documentation with some details about the release processes, in so working with the code bases of the application and its plugins becomes more expectable?