This guide explains how to release multiple app versions in the web-extensions monorepo using the multi-tag approach.

• Overview
• Step-by-Step Release Process
  • 1. Create a Feature Branch for Version Bumps
  • 2. Update Package Versions
  • 3. Commit and Push the Changes
  • 4. Create a Pull Request
  • 5. Get the Merge Commit Hash
  • 6. Create and Push Tags on the Merge Commit
  • 7. Monitor CI Builds
  • 8. Verify Releases
  • 9. Deployment Examples
• Technical Details
  • Tag Naming Convention
• Troubleshooting
  • Wrong Commit Tagged
• Quick Reference
• Files Modified in Each Release
• Docker Hub

The web-extensions repository uses a per-app versioning system where:

• Each app has its own independent version
• Multiple apps can be released from a single commit
• One merge commit on main can have multiple tags (one per app)
• Each tag triggers a separate CI pipeline for building and releasing that app
• Tags need to be signed when created

git checkout main
git pull origin main
git checkout -b chore/bump-versions

For each app that needs a version bump, update the version field in its package.json:

# Example: Updating cast app from 0.3.3 to 0.4.0
packages/web-app-cast/package.json
# Change: "version": "0.3.3" → "version": "0.4.0"

# Example: Updating unzip app from 0.4.3 to 0.5.0
packages/web-app-unzip/package.json
# Change: "version": "0.4.3" → "version": "0.5.0"

# ... repeat for other apps that need updates

Apps in this Repository:

• packages/web-app-advanced-search/
• packages/web-app-cast/
• packages/web-app-draw-io/
• packages/web-app-external-sites/
• packages/web-app-importer/
• packages/web-app-json-viewer/
• packages/web-app-jupyter/
• packages/web-app-photo-addon/
• packages/web-app-progress-bars/
• packages/web-app-unzip/

git add packages/*/package.json
git commit -m "chore: bump versions"
git push origin chore/bump-versions

Create a PR from your chore/bump-versions branch to main on GitHub.

Wait for approval and merge the PR. This creates a merge commit on main.

After the PR is merged, get the commit hash of the merge commit:

git checkout main
git pull origin main
git log --oneline | head -5
# Example output:
# 2524913 Merge pull request #318 from owncloud/chore/bump-versions
# abda7bb [tx] updated from transifex

The commit hash is 2524913 in this example.

Note that it would be possible to tag all web-extensions and push them in one step, but it has turned out that this will not trigger the release workflow. You therefore have to tag and push web-extensions individually which is proven to work.

When the tag is created, you will be asked to add a comment. As a rule of thumb, use as example:\t feat: advanced-search-v0.3.0

Create a tag of the app that was bumped, pointing to the exact merge commit from above:

# Create tags for each app (use the version you set in step 2)
git tag -s advanced-search-v0.3.0 2524913
git push origin --tags

git tag -s cast-v0.4.3 2524913
git push origin --tags

git tag -s draw-io-v0.4.0 2524913
git push origin --tags

git tag -s external-sites-v0.4.0 2524913
git push origin --tags

git tag -s importer-v0.4.0 2524913
git push origin --tags

git tag -s json-viewer-v0.4.0 2524913
git push origin --tags

git tag -s photo-addon-v0.3.0 2524913
git push origin --tags

git tag -s progress-bars-v0.4.0 2524913
git push origin --tags

git tag -s unzip-v0.5.0 2524913
git push origin --tags

Watch the builds on GitHub Actions:

• GitHub Actions: https://github.com/owncloud/web-extensions/actions

Each tag push triggers a separate build that:

1. Detects the tag (e.g., draw-io-v0.4.0)
2. Extracts the app name (draw-io) and version (0.4.0)
3. Builds that specific app
4. Creates a .zip artifact
5. Creates a GitHub release
6. Uploads the artifact to the release
7. Builds and pushes a Docker image

Once builds complete, check:

• GitHub Releases: https://github.com/owncloud/web-extensions/releases
• GitHub Tags: https://github.com/owncloud/web-extensions/tags
• Docker Hub: https://hub.docker.com/r/owncloud/web-extensions

You can now update the image versions of the ocis_full deployment examples.

Tags follow the pattern: {app-name}-v{version}

Examples:

• cast-v0.4.0
• draw-io-v0.4.0
• unzip-v0.4.0

If you tagged the wrong commit:

1. Delete local and remote tags:

   git tag -d cast-v0.4.0
   git push origin --delete cast-v0.4.0

2. Create tags on the correct commit:

   git tag -s cast-v0.4.0 2524913
   git push origin cast-v0.4.0

# 1. Create and switch to feature branch
git checkout -b chore/bump-versions

# 2. Update package.json versions

# 3. Commit and push
git add packages/*/package.json
git commit -m "chore: bump versions"
git push origin chore/bump-versions

# 4. Merge PR to main

# 5. Get merge commit hash and create tags
COMMIT=$(git log origin/main --oneline -1 | awk '{print $1}')
git tag -s app1-vX.Y.Z $COMMIT
git tag -s app2-vX.Y.Z $COMMIT
# ... etc for all apps

# 6. Push tags one by one
git push origin --delete app1-vX.Y.Z && git push origin app1-vX.Y.Z
git push origin --delete app2-vX.Y.Z && git push origin app2-vX.Y.Z
# ... etc

# 7. Monitor on GitHub Actions

When you create a release, these files are updated:

• packages/web-app-{name}/package.json - Version number

The CI/CD pipeline automatically:

• Builds the apps
• Creates GitHub releases with .zip artifacts
• Builds Docker images

You do not need to manually:

• Create GitHub releases (done by GHA)
• Build .zip files (done by GHA)
• Upload artifacts (done by GHA)

After successfully creating a new version, the relevant app image is made downloadable on Docker Hub.