Skip to content

RELEASE.md

Latest commit

 

History

History
38 lines (24 loc) · 2.26 KB

RELEASE.md

File metadata and controls

38 lines (24 loc) · 2.26 KB
Raw

Webify Pro release builds

GitHub Actions builds the platform-native release files:

  • Build Windows Setup creates Webify-Pro-<version>-Windows-Setup.exe on a Windows runner.
  • Build Android APK creates an installable debug APK for manual workflow runs, or a signed release APK for version tags.
  • Build macOS and Linux Releases creates verified macOS DMGs for Apple Silicon and Intel, plus a smoke-tested Linux x86_64 archive.

Android signing secrets

Create one long-lived Android release keystore and keep it backed up outside the repository. Add these GitHub Actions secrets:

  • ANDROID_KEYSTORE_BASE64: the keystore encoded with base64.
  • ANDROID_KEYSTORE_PASSWORD: keystore password.
  • ANDROID_KEY_ALIAS: release key alias.
  • ANDROID_KEY_PASSWORD: release key password.

Never commit the keystore or passwords. Android updates must be signed with the same key.

LamaTech local signing backup

The primary LamaTech development Mac keeps the long-lived Android signing files under the git-ignored local path .signing/android/. The PKCS#12 keystore is named webify-pro-release.p12 and its alias is webify-pro-release. Its keystore and key passwords are stored in macOS Keychain under these service names:

  • Webify Pro Android Keystore Password
  • Webify Pro Android Key Password

Back up the .p12 file and its passwords in a second secure, encrypted location. Losing either one prevents future Android releases from updating the installed application.

Create a release

  1. Run all three workflows manually to validate the builds.
  2. Configure the four Android signing secrets.
  3. Push a version tag such as v4.0.0.
  4. The workflows build and attach the Windows installer, signed Android APK, both macOS DMGs, and Linux x86_64 archive to one GitHub release.

The Windows installer is not Authenticode-signed unless a Windows code-signing certificate is added separately. The macOS workflow uses ad-hoc signing for bundle integrity; public distribution without a Gatekeeper warning requires an Apple Developer ID certificate and notarization.

The Windows and macOS desktop packages are built from the same src/webp_pro_v4.py application source, so their conversion features and interface are identical. Platform workflows only change the executable packaging format.