- Things in here have a very simple publishing stage of `pnpm publish`
- Things in here do not support pre-releases & hotfixes
-`modules` - this directory will hold some Element Web/Desktop modules we maintain in order to add environment-specific functionalities atop Element
- Things in here are not published to npm
### Branches
-`develop` - this is the default branch and should always be buildable, this is what developers use as a base branch for their pull requests
- Deployed via CD to develop.element.io
-#TODO should we just use short-lived release branches? We'd need to effectively interlace them for the various packages which feels messy
-`staging` - this branch is used to build the latest/next release.
- During a normal release cycle, `develop` is merged into `staging` to "cut" a release candidate
- Additional changes such as version bumps & changelogs are committed on top
- During a hotfix/security release, changes are directly cherry-picked to `staging` to "cut" a release based on the last release rather than `develop`
- When a release is finished, i.e. we've shipped the final release for a given version, we merge `staging->develop` to maintain continuity
-`backport/*` - these branches are used for cherry-picking entire pull requests from `develop` to `staging`, either to patch a release candidate, or to perform a hotfix release
-`<username>/*` - these feature branches are used for development, and may branch off `develop` or another feature branch
### Tags
-`v*` - these tags are used by the releases shown in the Github Releases UI, as in, the overall app release group
-`<package>@*` - these tags represent the release state of an individual npm package from the `packages/*` dir
Ultimately, the treatment of the 3 types of submodules we host in this repository is quite asymmetrical but this is by design,
to simplify processes around projects which do not need the complexities of element-web & element-desktop.
