If you're seeing this document, you are an early contributor to the development and success of XMTP. We welcome your questions, feedback, suggestions, and code contributions.
Have a question? We welcome you to ask it in Q&A discussions.
Bugs should be reported as GitHub Issues. Please confirm there isn't already an open issue and include detailed steps to reproduce.
These should also be submitted as GitHub Issues. Again, please confirm there isn't already an open issue. Let us know what use cases this feature would unlock so that we can investigate and prioritize.
PRs are encouraged, but we suggest starting with a Feature Request to temperature-check first. If the PR would involve a major change to the protocol, it should be fleshed out as an XMTP Improvement Proposal before work begins.
A new version of this package will be automatically published whenever there is a merge to the main branch. Specifically, new GitHub releases and tags will be created, and a new NPM package version will be published. The release version increment type is derived from the format of the commit messages that were bundled in the merge to main, using semantic-release commit message conventions.
The table below shows example commits and the resulting release type for a pencil project:
| Commit message | Release type |
|---|---|
docs: describe scribble feature |
No Release |
test: fix failing unit test |
No Release |
fix: stop graphite breaking when too much pressure applied |
|
feat: add 'graphiteWidth' option |
|
perf: remove graphiteWidth optionBREAKING CHANGE: The graphiteWidth option has been removed.The default graphite width of 10mm is always used for performance reasons. |
(Note that the BREAKING CHANGE: token must be in the footer of the commit) |
This is currently configured to use the Angular Commit Message Conventions. e.g. feat: add message signing would cause a minor release.
If there are multiple commits within a single pull request, each commit will be listed as a separate bullet point in the release notes and bundled together in a release of the highest increment type specified.
If your commit messages are not to your liking, it is permitted to rewrite the history on your branch and force-push it before merging it. Make sure you are never force-pushing on main, and that the following is in your ~/.gitconfig file.
[push]
default = simple
A beta release of this package will be automatically published whenever there is a merge to the beta branch. For more information on the beta branch pre-release workflow, see semantic-release pre-release workflow.
We should only target the beta branch when new functionality would benefit from early testing by downstream clients. Otherwise, features and fixes that are easily testable without input from downstream clients should be targeted against the main branch as usual.