We aim for the main branch of the repository to always be in a releasable state.
Two types of artifacts can be published:
1. Snapshot — An unstable release of the library for testing
1. Release — A stable release of the library
Control of these modes of release is managed with a Gradle property `IS_SNAPSHOT`.
For both snapshot and release publishing, there are two ways to initiate deployment:
1. Automatically
2. Manually
This document will focus initially on the automated process, with a section at the end on manual process. (The automated process more or less implements the manual process via GitHub Actions.)
# Automated Publishing
## Snapshots
All merges to the main branch trigger an automated [snapshot deployment](https://github.com/zcash/kotlin-bip39/actions/workflows/deploy-snapshot.yml).
Note that snapshots do not have a stable API, so clients should not depend on a snapshot. The primary reason this is documented is for testing, e.g. before deploying a new production version of the library we may test against the snapshot first.
// Optional; ensures only explicitly declared dependencies come from this repository
content {
includeGroup("cash.z.ecc.android")
}
}
}
}
```
2. Changing the dependency version to end with `-SNAPSHOT`
3. Rebuilding
`./gradlew assemble --refresh-dependencies`
Because Gradle caches dependencies and because multiple snapshots can be deployed under the same version number, using `--refresh-dependencies` is important to ensure the latest snapshot is pulled.
## Releases
Production releases can be consumed using the instructions in the [README.MD](../README.md). Note that production releases can include alpha or beta designations.
Automated production releases still require a manual trigger. To do a production release:
1. Update the [CHANGELOG.MD](../CHANGELOG.md) for any new changes since the last production release.
1. Run the [release deployment](https://github.com/zcash/kotlin-bip39/actions/workflows/deploy-release.yml).
1. Confirm deployment succeeded by modifying the [Secant Android Wallet](https://github.com/zcash/secant-android-wallet) to consume the new version.
1. Create a new Git tag for the new release in this repository.
1. Create a new pull request bumping the version to the next version (this ensures that the next merge to the main branch creates a snapshot under the next version number).
# Manual Publishing
See [ci.md](ci.md), which describes the continuous integration workflow for deployment and describes the secrets that would need to be configured in a repository fork.
1. Update the [build number](https://github.com/zcash/kotlin-bip39/blob/main/gradle.properties) and the [CHANGELOG](https://github.com/zcash/kotlin-bip39/blob/main/CHANGELOG.md). For release builds, suffix the Gradle invocations below with `-PIS_SNAPSHOT=false`.