From e0e4235354f470d07e1160618b5e5a4bf4b9967b Mon Sep 17 00:00:00 2001 From: Nik Clayton Date: Tue, 19 Sep 2023 16:40:07 +0200 Subject: [PATCH] change: Deprecate the "develop" branch (#70) The separation between the `develop` and `main` branches was inherited from Tusky and isn't helpful, complicating the release process and causing CI to repeatedly run the same actions on the same code. Deprecate the `develop` branch by removing references to it in the documentation and updating the CI configuration as necessary. Separately, the GitHub settings will be changed to set `main` as the default branch, and the `develop` branch will be deleted. --- .github/workflows/ci.yml | 2 +- .github/workflows/ktlint.yml | 2 +- .../workflows/populate-gradle-build-cache.yml | 6 +++--- .../upload-blue-release-google-play.yml | 2 +- docs/contributing/code.md | 18 +++++++++--------- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 6e56402f3..c55cb943f 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -29,7 +29,7 @@ jobs: - name: Gradle Build Action uses: gradle/gradle-build-action@v2 with: - cache-read-only: ${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/develop' }} + cache-read-only: ${{ github.ref != 'refs/heads/main' }} - name: ktlint run: ./gradlew clean ktlintCheck diff --git a/.github/workflows/ktlint.yml b/.github/workflows/ktlint.yml index 7df4f926d..cdecb096a 100644 --- a/.github/workflows/ktlint.yml +++ b/.github/workflows/ktlint.yml @@ -25,7 +25,7 @@ jobs: - uses: gradle/gradle-build-action@v2 with: - cache-read-only: ${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/develop' }} + cache-read-only: ${{ github.ref != 'refs/heads/main' }} - run: chmod +x ./gradlew diff --git a/.github/workflows/populate-gradle-build-cache.yml b/.github/workflows/populate-gradle-build-cache.yml index afa020b95..082c7fb13 100644 --- a/.github/workflows/populate-gradle-build-cache.yml +++ b/.github/workflows/populate-gradle-build-cache.yml @@ -1,4 +1,4 @@ -# Build the app on each push to `develop`, populating the build cache to speed +# Build the app on each push to `main`, populating the build cache to speed # up CI on PRs. name: Populate build cache @@ -6,7 +6,7 @@ name: Populate build cache on: push: branches: - - develop + - main jobs: build: @@ -28,7 +28,7 @@ jobs: - uses: gradle/gradle-build-action@v2 with: - cache-read-only: ${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/develop' }} + cache-read-only: ${{ github.ref != 'refs/heads/main' }} - name: Run app:buildOrangeDebug run: ./gradlew app:buildOrangeDebug diff --git a/.github/workflows/upload-blue-release-google-play.yml b/.github/workflows/upload-blue-release-google-play.yml index 96ea1640c..0c32e78d1 100644 --- a/.github/workflows/upload-blue-release-google-play.yml +++ b/.github/workflows/upload-blue-release-google-play.yml @@ -25,7 +25,7 @@ jobs: - name: Gradle Build Action uses: gradle/gradle-build-action@v2 with: - cache-read-only: ${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/develop' }} + cache-read-only: ${{ github.ref != 'refs/heads/main' }} - name: Build APK run: ./gradlew assembleBlueRelease --stacktrace diff --git a/docs/contributing/code.md b/docs/contributing/code.md index 8ea181af2..554ed6426 100644 --- a/docs/contributing/code.md +++ b/docs/contributing/code.md @@ -93,7 +93,7 @@ Pull requests (PRs) are the primary unit of collaboration for code. ### Work on branches in your own fork of the repository -Do not clone the `pachli-android` repository. Instead, create a fork, create a branch in your fork from the `develop` branch, and commit your changes to that. +Do not clone the `pachli-android` repository. Instead, create a fork, create a branch in your fork from the `main` branch, and commit your changes to that. See the GitHub [Collaborating with pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models) documentation. @@ -118,7 +118,7 @@ This is not mandatory, but may make developing easier for you. A PR is typically made up multiple commits. -With very few exceptions this project squash-merges all PRs to maintain a linear commit history on the `develop` branch. +With very few exceptions this project squash-merges all PRs to maintain a linear commit history on the `main` branch. Therefore **we do not care** about the "quality" of the individual commits that make up a single PR. Within the PR a single commit might change multiple things, have a non-obvious commit message, be littered with `TODO` comments, etc. Please do not think that every commit you make as you complete your PR needs to be perfect. @@ -240,15 +240,15 @@ As well as conveying more information to me as the reviewer this allows me to pe - Are there other instances of `@color/white` that this PR missed? - Does the PR use the correct spelling of `colorControlNormal` everywhere? -#### Cleanly merge back in to `develop` +#### Cleanly merge back in to `main` -While you were working on your PR other changes may have happened on the `develop` branch. +While you were working on your PR other changes may have happened on the `main` branch. -Some of those changes may have overlapped with changes you make in your PR, and your PR can not be merged cleanly back in to `develop`. +Some of those changes may have overlapped with changes you make in your PR, and your PR can not be merged cleanly back in to `main`. -You should periodically merge changes from the `develop` branch in to your PR branch, and keep your PR up to date with `develop` during the review process. +You should periodically merge changes from the `main` branch in to your PR branch, and keep your PR up to date with `main` during the review process. -If your PR can not be cleanly merged in to `develop` it is difficult to review effectively, because merging the changes from `develop` in to your PR will invalidate the review. You've changed the code, so the reviewer needs to look at it again. +If your PR can not be cleanly merged in to `main` it is difficult to review effectively, because merging the changes from `main` in to your PR will invalidate the review. You've changed the code, so the reviewer needs to look at it again. #### `ktlintCheck` and `ktlintFormat` @@ -317,7 +317,7 @@ On the GitHub page for your PR create a new comment, and paste (Ctrl-V / Cmd-V) This checklist may be helpful when you are creating your first few PRs. The PR: - [ ] ... is made from my fork of the Pachli repository -- [ ] ... is branched from `develop` +- [ ] ... is branched from `main` - [ ] ... title follows Conventional Commits: - [ ] starting with the correct type (`fix:`, `feat:`, etc) - [ ] and makes sense prefixed with "If merged, this PR will ..." @@ -326,7 +326,7 @@ This checklist may be helpful when you are creating your first few PRs. The PR: - [ ] What it does - [ ] If appropriate, a justification for the approach - [ ] And has a "Fixes ..." footer if it fixes an issue -- [ ] ... merges cleanly in to the `develop` branch +- [ ] ... merges cleanly in to the `main` branch - [ ] ... passes `ktlintCheck` - [ ] ... passes all tests - [ ] ... and adds new ones if appropriate