Release Management Process and Packaging
The release process crew improves and maintains the release process, its implementation and the architecture that runs it. It also created and maintains the performance regression test framework (PRT).
See the board for an overview of issues.
Goals
-
bootstrap a performance regression test framework -
revamp pipelines and release branches -
do not rely on GitLab tarballs, publish our own tarballs -
CI runners for Umami (Windows and Mac) -
streamline the creation of release branches -
automatically publish opam packages -
convert everything to the manifest -
automate generation of .opam
files for releases -
plug this into the CI to generate the PR link automatically
-
-
automatically publish Debian packages -
rename tezos-*
intooctez-*
(executables and opam packages) - maintain:
- CI runners
- performance regression test framework executors
- release pipeline specifications (GitLab's YAML)
- release branches
- release repositories where we store release artefacts
Original Milestone Description
Goal: improve the process employed to release the software developed in the Tezos core code base to minimize required work once we decide that a release needs to be made. Ideally, once the merge requests for required features and bug fixes have been merged, releasing should only require the push of a button that several people could push.
Identify pain points in the process:
- anything which may block a release;
- anything which makes the process slower;
- anything which requires human action.
Then eliminate those pain points. If they can't be eliminated, reduce them and explain why they cannot be reduced further.
Document the resulting process so that:
- the automated parts are easy to identify and maintain;
- the non-automated parts are in a checklist.
Here is a list of items to consider.
- Create a release management team and governance for that team; the team will govern the formal release process.
- Create a published schedule for software and protocol releases and expectations around the updates to that schedule.
- Decide on what degree of packaging (.rpm, .deb, etc.) should be employed by the project.
- Automate release builds.
- Automate packaging of release builds.
- Automate system testing of released packages.
- Automate system testing of release candidates with realistically-sized networks.
- Define, publish, and automate a branching strategy for releases (e.g. https://wiki.debian.org/DebianReleases).
- Define continuous processes for updating release notes so that a release does not require additional documentation efforts.