Releasing Guide
To prepare an oCIS production release, you must follow a specific sequence of steps in the correct order.
New oCIS Version
Use these detailed copy/paste checklists for Jira when starting a new release.
|
Steps for Major or Minor Releases
|
Overview
-
Start the Releasing Process
-
Start the Release Candidates Phase
-
Prepare Release
Integrate all RC changes and set the final version -
Sign-off the Releasing Process
-
Release the new Version
-
Postprocessing and Finalization
Backport changes tomasterand create other required stable branches, update cronjobs and clean up
Details
https://doc.owncloud.com/ocis/releasing_guide/releasing_guide.html
* [ ] Start the Releasing Process
* [ ] Create a `stable-8.2` branch based on current `master`
* [ ] Inform documentation that the releasing process has started
* [ ] Start the Release Candidates Phase
* [ ] Create a new feature branch based on `stable-8.2`
* [ ] Move all changelog items from `unreleased` to `8.2.0-rc.1_2025-06-12`
* [ ] Bump oCIS version in `ocis-pkg/version/version.go`
* [ ] Bump oCIS version in `sonar-project.properties`
* [ ] Create PR with `[full-ci][k6-test]` against `stable-8.2`
* [ ] Get PR approved. **DO NOT MERGE YET**
* [ ] Wait for pipeline to be green
* [ ] Create tag: `git tag -s v8.2.0-rc.1 -m "Release 8.2.0-rc.1"`
* [ ] Push tag: `git push origin v8.2.0-rc.1`
* [ ] Watch the PR to see pipeline succeed (can be restarted)
* [ ] Merge PR
* [ ] Sync with DevOps and Product\
Repeat process with `rc.2`,`rc.3`, ...
* [ ] All required translations from oCIS are included
* [ ] All issues are fixed, RC phase has finished
* [ ] Prepare Release
* [ ] Create a new feature branch based on `stable-8.2`
* [ ] Move all changelog items from `8.2.0-rc.*` to `8.2.0_2025-04-01`
* [ ] Bump oCIS version in `ocis-pkg/version/version.go`
* [ ] Bump oCIS version in `sonar-project.properties`
* [ ] Create PR with `[full-ci][k6-test]` against `stable-8.2`
* [ ] Mark PR as **Draft** to avoid accidentially merging
* [ ] Get PR approved. **DO NOT MERGE YET**\
Info: merging will be done in step *Release the new Version*
* [ ] Wait for pipeline to be green
* [ ] Get new Release Sign-off (jira)
* [ ] **EITHER (preferred):** Find someone who wants the release more than you do, and have them sign-off
* [ ] **OR (not recommended):** Have the appropriate people sign the *release sign-off* document
* [ ] Release the new Version
* [ ] Create tag: `git tag -s v8.2.0 -m "Release 8.2.0"`\
Note the tag name scheme is important
* [ ] Push tag: `git push origin v8.2.0`
* [ ] Watch the PR to see pipeline succeed (can be restarted)
* [ ] Smoke test docker image `owncloud/ocis@v8.2.0`
* [ ] Choose any docker-compose example from oCIS repository
* [ ] Export `OCIS_DOCKER_IMAGE=owncloud/ocis`
* [ ] Export `OCIS_DOCKER_TAG=8.2.0`
* [ ] `docker compose up -d`
* [ ] Confirm oCIS version in browser and start the `upload-download-awesome` test
* [ ] Remove the **Draft** state and Merge PR\
This is the PR from step *Prepare Release*
* [ ] Delete the feature branch
* [ ] Announce release in *Teams channel: oCIS*
* [ ] Postprocessing and Finalization
* [ ] Backport `stable-8.2` to the master branch
* [ ] Create a `docs-stable-8.2` branch
* [ ] Create orphan branch: `git checkout --orphan docs-stable-8.2`
* [ ] Initial commit: `git commit --allow-empty -m "initial commit"`
* [ ] Push it: `git push`
* [ ] Add `stable-8.2` to the nightly cron jobs in drone (`Settings` -> `Cron Jobs`)
Steps for Patch Releases Only
|
Overview
-
Prepare Release
Integrate all patches and set the final version -
Sign-off the Releasing Process
-
Release the new Version
-
Check Forward Porting to Master
Details
https://doc.owncloud.com/ocis/releasing_guide/releasing_guide.html
* [ ] Prepare Release
* [ ] Create a new feature branch based on `stable-8.2`
* [ ] Move all changelog items from `unreleased` to `8.2.1_2026-07-01`
* [ ] Bump oCIS version in `ocis-pkg/version/version.go`
* [ ] Bump oCIS version in `sonar-project.properties`
* [ ] Create PR with `[full-ci][k6-test]` against `stable-8.2`
* [ ] Mark PR as **Draft** to avoid accidentially merging
* [ ] Get PR approved **requires 2 approvals**, **DO NOT MERGE YET**\
Info: merging will be done in step *Release the new Version*
* [ ] Wait for pipeline to be green
* [ ] Get new Release Sign-off (confluence)
* [ ] **EITHER (preferred):** Find someone who wants the release more than you do, and have them sign-off
* [ ] **OR (not recommended):** Have the appropriate people sign the *release sign-off* document
* [ ] Release the new Version
* [ ] Create tag: `git tag -s v8.2.1 -m "Release 8.2.1"`\
Note the tag name scheme is important
* [ ] Push tag: `git push origin v8.2.1`
* [ ] Watch the PR to see pipeline succeed (can be restarted)
* [ ] Smoke test docker image `owncloud/ocis@v8.2.1`
* [ ] Choose any docker-compose example from ocis repository
* [ ] Export `OCIS_DOCKER_IMAGE=owncloud/ocis`
* [ ] Export `OCIS_DOCKER_TAG=8.2.1`
* [ ] `docker compose up -d`
* [ ] Confirm oCIS version in browser and start the `upload-download-awesome` test
* [ ] Remove the **Draft** state and Merge PR\
This is the PR from step *Prepare Release*
* [ ] Delete the feature branch
* [ ] Announce release in *Teams channel: oCIS*
* [ ] Check if Forward Porting to Master is Required
Update Documentation Related Data
Envvar Changes
Follow the Release Process for Envvars documentation to update the required environment variable data. These changes must be present in the appropriate stable-8.2 branch and should be applied to the respective feature branch during the development cycle. This avoids manually backporting to stable-8.2 but may be required if changes go to master instead. Changes to envvars are typically found in the docs folder.
|
The admin docs processes access the data via the branch name, not the tag set. Therefore, any changes applied to the stable branch are accessible to the documentation process without the need of a new version. |
Prepare Admin Docs
The admin documentation must be prepared for the new release.
Note that this section is only informational for oCIS developers and is done by the documentation team. This is why they need to be informed in a timely manner.
* [ ] Create _overview release notes_ in the `ROOT` module of the `main` component\
in the `docs.owncloud.com` repo based on the changelog\
The source is most likely the unreleased folder during the development cycle
* [ ] For Major and Minor versions:
* [ ] Add all _documentation changes_ including the upgrade guide in the `docs-ocis` repo in master
* [ ] Create a new release branch in the `docs-ocis` repo based off master
* [ ] _Update oCIS branches and versions_ in the `docs` repo
* [ ] For Patch releases:
* [ ] _Update oCIS versions_ in the `docs` repo