Usage

Add the desired library as following

implementation("me.proton.core:<name-of-the-lib>:<version>")

where <name-of-the-lib> reflect the one listed below, on lowercase, with - instead of spaces Util Android Shared Preferences: **0.1** can be resolved as me.proton.core:util-android-share-preferences:0.1

Where there are all or some of domain, data, presentation, they can be imported together with the parent module.

implementation("~:network-domain:~")
implementation("~:network-data:~")

or

implementation("~:network:~")

while the first one is suitable for multi-module projects, the latter is the suggested solution for monolithic clients.

Conventional Commits

• For each Merge Request, all commits must adhere to Conventional Commits spec.
• Whenever possible, use a module name as a scope (e.g. fix(account-manager): Fix login issue.).
• Use a proper sentence as a description — start with an uppercase letter, end with a dot.

Allowed commit types

• build^*: Changes that affect build system (e.g. Gradle update)
• chore: Changes other than source or test code (e.g. library version updates)
• ci^*: CI configuration
• docs^*: Documentation changes
• feat: A new feature
• fix: Bug fixes
• i18n: Internationalization and translations
• perf: Performance Improvements
• refactor: A change in the source code that neither fixes a bug nor adds a feature
• revert: Reverting a commit
• style^*: Code style changes, not affecting code meaning (formatting)
• test^*: Adding new tests or improving existing ones
• theme: Changes related to UI theming

^* Commits with those types, will be skipped when generating changelog.

Gradle tasks

• :my_module:projectHealth or buildHealth - Runs dependency analysis on a single module or the whole project.
• generateChangelog - Generates a changelog since the last release (tag). Output is written to CHANGELOG.md file.

Release

Core libraries

Release process is based on trunk branch for release process. Release is done by the CI.

To trigger a new release, navigate to the latest CI build on the main branch and launch the trigger-new-libs-release job. Before launching it, you can specify the next version number, by entering a NEXT_VERSION variable. If unspecified, the version number will be calculated automatically.

The trigger-new-libs-release job will generate and update the changelog, and commit the changes to the main branch. At this point you will be able to review the automatic changes. If the changes are correct, you should push a new branch named release/libs/X.Y.Z.

When the release is successfully done:

• A message is post on internal communication tool using the content of the CHANGELOG.MD under the entry `## [X.Y.Z].
• A tag release/libs/X.Y.Z is created from the commit used to do the release.

Version

• Stable release X.Y.Z are published on MavenCentral.
• Snapshot from every commit on the main branch are available using version main-SNAPSHOT under https://s01.oss.sonatype.org/content/repositories/snapshots/ repo.

Coordinates

Core libraries coordinates can be found under coordinates section