We regularly push improvements to Penrose, and we would like for you to stay up to date on our newest features and bugfixes!

The best way to do this is to just pull from main and rebuild whenever there is a new release, about weekly (we'll let you know on Slack).

New releases will be announced and tagged, with a changelog, on our GitHub releases page. Read that page to know what's new in each release.

To use a stable version of Penrose, we recommend installing the latest version, tagged latest, on our npm repository here (click "Versions" and look under "Published" to see the latest latest version).

New stable releases will be announced and tagged, with a changelog, on our GitHub releases page. Read that page to know what's new in each release.

We track releases in two places: GitHub and npm (click "Versions").

Feel free to bump the version (about weekly) if you want to get a new feature/bugfixes out to domain experts.

If you bump the version on GitHub (locally), it will automatically appear on npm. Our build system (lerna) will also auto-generate a changelog for it, separated by bugs and features, here.

Steps for bumping a release:

• Run yarn new-version locally. This does the release on GitHub.
  • You'll have to already have generated a personal GH_TOKEN on GitHub with release permissions and added to your shell environment.
• Run yarn release locally. This sends the release to npm.
  • You may need to run npm login at this step to authenticate.
• Go to GitHub and write a change log for the new release here. It should describe the user-facing and dev-facing changes that have happened since the last tagged release, noting which part of the system it applies to. If there are breaking changes, be sure to document what breaks, and how users should port their Penrose code to the new version.
  • See the 1.1.0 change log for an example of how to write a change log.
• Alert the other devs and collaborators on Slack, e.g. in #collaborators. (In the future, we could do this with a Slack integration.)

In general, we follow conventional commits, which allows changelogs to be auto-generated. Any breaking commits need to be marked with BREAKING CHANGE: , e.g. anytime you change the registry trios. Breaking changes will bump the version number.

(Note: Releases don't exist in git; they're a GitHub-only concept.)