You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
tauri-plugins-workspace/.changes
Amr Bashir 84b3612393
fix(window-state): port fixes from v1 (#436)
2 years ago
..
config.json fix(ci): enable sqlite feature when publishing the sql plugin 2 years ago
notification-init-script.md fix(notification): Fix init.js script for use without global tauri object. (#414) 2 years ago
notification-sound.md feat(notification): play default sound on WIndows 2 years ago
os-plugin-refactor.md feat(os): refactor and improvemnts (#419) 2 years ago
pre.json Publish New Versions (v2) (#402) 2 years ago
readme.md ci: set up covector (#329) 2 years ago
stronghold-constructor.md fix(stronghold): remove constructor, add static load function (#416) 2 years ago
v2-alpha.md refactor: rename clipboard plugin to clipboard-manager (#400) 2 years ago
window-state-decorated.md fix(window-state): port fixes from v1 (#436) 2 years ago
window-state-promise.md fix(window-state): port fixes from v1 (#436) 2 years ago

readme.md

Changes

via https://github.com/jbolda/covector

As you create PRs and make changes that require a version bump, please add a new markdown file in this folder. You do not note the version number, but rather the type of bump that you expect: major, minor, or patch. The filename is not important, as long as it is a .md, but we recommend that it represents the overall change for organizational purposes.

When you select the version bump required, you do not need to consider dependencies. Only note the package with the actual change, and any packages that depend on that package will be bumped automatically in the process.

Use the following format:

---
"package-a": patch
"package-b": minor
---

Change summary goes here

Summaries do not have a specific character limit, but are text only. These summaries are used within the (future implementation of) changelogs. They will give context to the change and also point back to the original PR if more details and context are needed.

Changes will be designated as a major, minor or patch as further described in semver.

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards compatible manner, and
  • PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format, but will be discussed prior to usage (as extra steps will be necessary in consideration of merging and publishing).