Skip to content

Latest commit

 

History

History
91 lines (66 loc) · 4.53 KB

DEVELOPMENT.md

File metadata and controls

91 lines (66 loc) · 4.53 KB
Raw

Development

Signum maintains two primary branches - main and development. development will always be strictly ahead of main. The two will never diverge.

Development of features is done in feature branches, which are based on development. Pull requests will be used to merge finished features from their feature branch into development. Each pull request will result in a single squashed feature commit on development, which references the original pull request. Pull requests must never be merged into main, since doing so would cause main and development to diverge.

Release process

Both main and development are branch-protected against direct commits. When finalizing a new release version (with main catching up to development), proceed as follows. If any of these steps fail unexpectedly, please consult with your fellow developers instead of making potentially-breaking changes to the Git tree.

  1. Create a new feature pull request against development, which updates CHANGELOG.md (removing the "NEXT" marker) and gradle.properties (to the release version).
  2. Merge this pull request as usual.
  3. Create a pull request from development against main. Do not merge this pull request using the GitHub UI, since doing so breaks the linear relationship between main and development.
  4. Once this pull request has been approved, manually merge it:
# make sure your local copy of the remote state is up-to-date
git fetch origin

# switch to your local main branch
git checkout main

# make sure your local main branch matches the remote main branch
git reset --hard origin/main 

# update your local main branch to the development branch without creating a merge commit
git merge --ff-only origin/development

# push your local main branch to the remote
git push origin main
  1. GitHub recognizes that your push is closing the pull request that you created, and will permit it despite the branch protection rule.
  2. Create a new tag for the release
  3. Publish the release
  4. Create a new feature pull request against development, which adds the next snapshot version to CHANGELOG.md and gradle.properties.
  5. Merge this pull request as usual.

Publishing

Create a GPG key with gpg --gen-key, and export it with gpg --keyring secring.gpg --export-secret-keys > ~/.gnupg/secring.gpg. Be sure to publish it with gpg --keyserver keyserver.ubuntu.com --send-keys <your-key-id>. See also the information in the Gradle docs.

Create a user token for your Nexus account on https://s01.oss.sonatype.org/ (in your profile) to use as sonatypeUsername and sonatypePassword.

Configure your ~/.gradle/gradle.properties:

signing.keyId=<last-8-chars>
signing.password=<private-key-password>
signing.secretKeyRingFile=<path-of-your-secring>
sonatypeUsername=<user-token-name>
sonatypePassword=<user-token-password>

To run the pipeline from GitHub, export your GPG key with gpg --export-secret-keys --armor <keyid> | tee <keyid>.asc and set the following environment variables:

ORG_GRADLE_PROJECT_signingKeyId=<last-8-chars>
ORG_GRADLE_PROJECT_signingKey=<ascii-armored-key>
ORG_GRADLE_PROJECT_signingPassword=<private-key-password>
ORG_GRADLE_PROJECT_sonatypeUsername=<user-token-name>
ORG_GRADLE_PROJECT_sonatypePassword=<user-token-password>

Actually, these environment variables are read from the repository secrets configured on Github.

Publish with:

./gradlew clean publishToSonatype

To also release the artifacts to Maven Central run:

./gradlew clean publishToSonatype closeAndReleaseSonatypeStagingRepository

To publish locally for testing, one can skip the signing tasks:

./gradlew clean publishToMavenLocal -x signJvmPublication -x signKotlinMultiplatformPublication -x signIosArm64Publication -x signIosSimulatorArm64Publication -x signIosX64Publication

Creating a new release

Create a release branch and do the usual commits, i.e. setting the version number and so on. Push it to Github. Run the workflow "Build iOS Framework", and attach the artefacts to the release info page on GitHub. Use the link from there to update the Swift Package, modifying Package.swift and entering the URLs. The checksum is the output of sha256sum *framework.zip.