From e165a62037554673e46526c3ccc53a2238fc56d8 Mon Sep 17 00:00:00 2001 From: Rahul Sharma Date: Sat, 3 Oct 2026 22:14:50 -0700 Subject: [PATCH] CONTRIBUTING: document CI and the PR-based release flow; add Dependabot for Actions main now requires the CI build to pass, with no bypass, so release commits go through a pull request too. Replace the four-line release section (which claimed a GitHub Action publishes releases; none does) with the actual steps, and describe what CI builds and how to read a failure. Dependabot keeps the actions in the workflow current; Swift packages stay hand-pinned on purpose. Co-Authored-By: Claude Fable 5.1 --- .github/dependabot.yml | 12 ++++++++++++ CONTRIBUTING.md | 36 ++++++++++++++++++++++++++++++++---- 2 files changed, 44 insertions(+), 4 deletions(-) create mode 100644 .github/dependabot.yml diff --git a/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 00000000..1c344f77 --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,12 @@ +# Keeps the GitHub Actions used by .github/workflows current. Swift packages are pinned by +# hand in project.yml on purpose (several of them rewrite their API between releases), so +# they are deliberately not covered here. +version: 2 +updates: + - package-ecosystem: github-actions + directory: / + schedule: + interval: monthly + labels: [ci] + commit-message: + prefix: "CI" diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 21a21525..f35c64bf 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -267,13 +267,41 @@ Types: - [ ] Documentation updated if needed - [ ] Tests added/updated - [ ] No compiler warnings introduced +- [ ] CI is green + +### Continuous integration + +Every pull request is compiled by GitHub Actions (`.github/workflows/ci.yml`): the app and its +test target are built for a generic iOS device with code signing off, on a free macOS runner. +`main` requires that check to pass before a PR can merge, and that applies to maintainers too. + +The workflow copies `Config.xcconfig.example` and `OpenVision/Config/Config.swift.example` into +place, so no secrets are needed to compile. If CI fails on your PR, open the job's log; the +`.xcactivitylog` files are attached as an artifact when the build step fails. ## Release Process -1. Version follows [Semantic Versioning](https://semver.org/) -2. Update `CHANGELOG.md` -3. Create release tag -4. GitHub Action builds and publishes +Releases are cut by a maintainer. Version numbers follow [Semantic Versioning](https://semver.org/): +a new backend or feature bumps the minor version, fixes alone bump the patch version. + +1. Open a release branch from `main` (for example `release/2.15.0`). +2. Update `CHANGELOG.md`: move everything merged since the last release under a new + `## [x.y.z] - YYYY-MM-DD` heading, grouped as Added / Changed / Fixed, with the PR number + on each line. +3. Bump `MARKETING_VERSION` and `CURRENT_PROJECT_VERSION` in `project.yml`, run `xcodegen generate`, + and commit as `Bump version to x.y.z (build N)`. +4. Open a pull request. `main` is protected, so the release commits go through CI like any + other change; direct pushes to `main` are rejected. +5. After the merge, tag the merge commit and publish the release with narrative notes and a + compare link: + + ```bash + git tag -a vx.y.z -m "OpenVision x.y.z" + git push origin vx.y.z + gh release create vx.y.z --title "OpenVision x.y.z" --notes-file notes.md + ``` + +The app is distributed as source; there is no App Store or TestFlight step in this repository. ## Questions?