Skip to content

Set Beta/Plus/Next branding and fetch stable translations on stable branch

Alvin Wong requested to merge alvinwong/krita:alvin/branding into master

Adds an uncomment-able define KRITA_STABLE_BRANCH for our stable branch. This variable affects the Plus/Next branding choice and the translation fetching branch.

This means after branching krita/5, @rempt should uncomment the set(KRITA_STABLE_BRANCH 1) line.

Also set the branding in specific conditions:

All (CMakeLists.txt):

  • If branding is passed to CMake, then it is used.
  • Otherwise, for beta and RC builds, the branding is set to Beta.
  • Otherwise, if KRITA_STABLE_BRANCH is defined then the branding is set to Plus.
  • Otherwise, the branding is set to Next.

Windows build.cmd:

  • If running on the master nightly builder (Krita_Nightly_Windows_Build), set branding to Next.
  • If running on the stable nightly builder (Krita_Stable_Windows_Build), set branding to Plus.
  • Otherwise, the branding is unset and left to the checking in CMakeLists.txt.

Linux AppImage build script:

The logic is replaced:

  • If running on the master nightly builder (Krita_Nightly_Appimage_Build), set branding to Next.
  • If running on the stable nightly builder (Krita_Stable_Appimage_Build), set branding to Plus.
  • Otherwise, the branding is unset and left to the checking in CMakeLists.txt.

(Actually, the above doesn't matter because the AppImage pipelines already pass the branding to the script.)

macOS build script:

  • If running on the master nightly builder (Krita_Nightly_MacOS_Build), set branding to Next.
  • If running on the stable nightly builder (Krita_Stable_MacOS_Build), set branding to Plus.
  • Otherwise, the branding is unset and left to the checking in CMakeLists.txt.

Updated version actually not tested, but I think should work...

Test Plan

  • Start a build and see what BRANDING value is printed from cmake.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • n/a I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
Edited by Alvin Wong

Merge request reports