Skip to content

22 ‐ How to update modules

Jump to bottom
Pierre-Yves Lapersonne edited this page Dec 17, 2024 · 1 revision

Create an issue

We need to trace any modifications, that is the reason why we need issues. You should use the dedicated issue template.

Submit a clean pull request

You may have to update several parts of the library to have a good implementation of the modules. Please, refer to CONTRIBUTING and DEVELOP.

Things to not forget

Maintain tests

  • Update if nedded the UI and unit tests (to test rendering of modules and its components, tokens, etc.)
  • Ensure every UI tests work and pass
  • Ensure every unit tests work and pass

Maintain the documentation

  • Check the documentation of the Swift files is enough (Xcode preview, minimap MARK, comments, code samples, etc)
  • Check the DocC catalogs are updated (code samples, how to use the modules, etc).
  • Update the CHANGELOG

No warnings

  • Check the SwiftLint does not through warnings nor errors
  • Build locally using Xcode the documentation and check if some warnings appear

Build alpha version or check locally

If needed, build an alpha release using the CI/CD pipeline job, or at least build locally the app with the update tokens and check modifications.

Merge with a nice commit

Finaly, merge the things into develop with the squash and merge commit mode, using conventional commit messages rules. If you bring breaking changes (i.e. remove or rename tokens, components, modules, or properties, thus breaking public API and retrocompatiblity), use the ! symbol. You should prefer refactor keyword if module is refactored, or feat if new module is added. If the changes are very small, maybe chore is enough, it is up to you and the code reviewers to define.

For example, for an update of module "MoreApps" with internal changes, for issue number "abc" and pull request number "def":

refactor: improve `MoreApps` (#abc) (#def)

Add details on the commit body about the changes

But if you break public API of the components:

refactor!: improve `MoreApps` (#abc) (#def)

Add details in the commit body about non-breaking changes

BREAKING CHANGE: Add details in commit body about the breaking changes

And if the module is new:

feat: add `MoreApps` module (#abc) (#def)

Add details in the commit body about changes
Clone this wiki locally