Conversation
Document branch strategy (master for stable, develop for active work), branch naming conventions, release process, and project structure. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds contributor and AI-assistant guidance docs to standardize development workflow and provide project context.
Changes:
- Added
CONTRIBUTING.mddocumenting branch strategy, release process, development setup, and quality checks. - Added
CLAUDE.mddescribing project context, build commands, module structure, and conventions for AI-assisted development.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| CONTRIBUTING.md | Documents contribution workflow (branches, naming, release steps, local setup, quality tools). |
| CLAUDE.md | Captures concise repo context (modules, build commands, conventions) for AI/dev tooling. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - **Never push directly to `master`.** All changes go through `develop` first. | ||
| - **`develop` → `master`** merge happens only when preparing a release. | ||
| - Feature branches are created from `develop` and merged back into `develop` via PR. | ||
| - Hotfix branches are created from `master`, merged into both `master` and `develop`. |
There was a problem hiding this comment.
Branch strategy says feature branches merge via PR into develop, but the repo's PR CI workflow (.github/workflows/android.yml) is configured to run only for PRs targeting master. If develop is the intended PR target, update the workflow to include develop (or adjust this doc to match the current CI behavior), otherwise contributors won't get CI feedback on PRs to develop.
| ``` | ||
| feature/xyz ──PR──► develop ──release──► master ──tag──► v2.0.5 | ||
| │ | ||
| GitHub Actions | ||
| publishes to | ||
| Maven Central | ||
| ``` |
There was a problem hiding this comment.
The workflow diagram states GitHub Actions publishes to Maven Central as part of the develop→master→tag flow, but the repository currently has no workflow triggered by tags/releases (only android.yml on master and build.yml on develop). Please update the diagram (and/or add the missing release workflow) so contributors aren't relying on a CI flow that doesn't exist in this repo.
| git tag vX.Y.Z | ||
| git push origin master --tags | ||
| ``` | ||
| 5. CI automatically: validates version → runs checks → publishes to Maven Central → creates GitHub Release |
There was a problem hiding this comment.
Step 5 claims CI will validate the version, run checks, publish to Maven Central, and create a GitHub Release, but there is no release/publish GitHub Actions workflow in .github/workflows/ to do this. Either adjust the release steps to reflect the current manual process, or add the automation so the documented process is accurate.
|
|
||
| 1. Clone the repository | ||
| 2. Open in Android Studio | ||
| 3. For local publishing, create `local.properties` with signing and Maven Central credentials |
There was a problem hiding this comment.
The instructions mention adding signing + Maven Central credentials to local.properties, but don't explicitly remind contributors that this file contains secrets and must not be committed (even though it's currently gitignored). Please add a short note to avoid accidental credential leaks, and consider listing the expected property keys (signing.*, mavenCentralUsername, mavenCentralPassword) to reduce setup friction.
| 3. For local publishing, create `local.properties` with signing and Maven Central credentials | |
| 3. For local publishing, create a `local.properties` file (not checked into version control) containing your signing and Maven Central credentials. This file contains secrets and must never be committed. | |
| Example properties: | |
| ```properties | |
| signing.keyId=... | |
| signing.password=... | |
| signing.secretKeyRingFile=/absolute/path/to/your/secring.gpg | |
| mavenCentralUsername=... | |
| mavenCentralPassword=... |
CLAUDE.md
Outdated
| - `master` — stable, released code. Never push directly. | ||
| - `develop` — active development. All feature branches merge here. | ||
| - Feature branches: `feature/<name>`, `fix/<name>`, `chore/<name>`, `docs/<name>` | ||
| - PRs always target `develop`, except hotfixes which target `master` (and then merge into `develop` too). |
There was a problem hiding this comment.
This says PRs always target develop, but the repo's PR CI workflow (.github/workflows/android.yml) is configured to run only when the PR target branch is master. Either update the workflow(s) to run on PRs to develop or adjust this guidance so it matches what CI actually enforces.
| - PRs always target `develop`, except hotfixes which target `master` (and then merge into `develop` too). | |
| - PRs normally target `develop`, but CI is currently configured to run only for PRs targeting `master`. Open or retarget PRs to `master` when you need full CI validation (hotfixes always target `master` and then merge into `develop`). |
CLAUDE.md
Outdated
| - `develop` — active development. All feature branches merge here. | ||
| - Feature branches: `feature/<name>`, `fix/<name>`, `chore/<name>`, `docs/<name>` | ||
| - PRs always target `develop`, except hotfixes which target `master` (and then merge into `develop` too). | ||
| - Release: merge `develop` → `master`, tag `vX.Y.Z`, push tag to trigger CI release. |
There was a problem hiding this comment.
The release guidance says pushing a vX.Y.Z tag triggers a CI release, but this repo currently has no GitHub Actions workflow configured to run on tag pushes (only branch pushes on master/develop). Please update this note (or add a tag-triggered release workflow) so the documented release process matches reality.
| - Release: merge `develop` → `master`, tag `vX.Y.Z`, push tag to trigger CI release. | |
| - Release: merge `develop` → `master` to trigger CI release, then tag `vX.Y.Z` on `master` for the released version. |
CLAUDE.md
Outdated
| - Version is in `gradle/libs.versions.toml` under `vbpd` | ||
| - Convention plugins apply Detekt, ktlint, Kover to all library modules | ||
| - Publishing uses Vanniktech Maven Publish to Sonatype Central Portal | ||
| - CI credentials via `ORG_GRADLE_PROJECT_*` env vars; local via `local.properties` |
There was a problem hiding this comment.
This claims CI credentials are provided via ORG_GRADLE_PROJECT_* env vars, but there is no CI publishing workflow in the repo demonstrating those variables being set/used. Consider rephrasing to a verifiable statement (e.g., "Gradle properties can be provided via ORG_GRADLE_PROJECT_*") or adding the corresponding CI configuration so contributors know how releases are actually authenticated.
| - CI credentials via `ORG_GRADLE_PROJECT_*` env vars; local via `local.properties` | |
| - Gradle properties (including credentials) can be provided via `ORG_GRADLE_PROJECT_*` env vars; local via `local.properties` |
…ands Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary
CONTRIBUTING.mdwith branch strategy, naming conventions, release process, and development setupCLAUDE.mdwith project context for AI-assisted developmentBranch strategy documented:
master— stable, released code (never push directly)develop— active development (all feature branches merge here)feature/,fix/,chore/,docs/develop→master→ tag → CI publishesTest plan
🤖 Generated with Claude Code