764e8f7719
* feat(autostart): add prefered name configuration for auto start entry - Add PreferedName enum to support different naming strategies - Implement Default trait for PreferedName with PackageInfoName as default - Add prefered_name builder method with documentation and examples - Integrate prefered name into auto start configuration This change allows users to customize the name of their application in the auto start entry using various naming strategies like package info name, crate name, config identifier, or custom name. * refactor(autostart): rename prefered_name to app_name and update related logic - Change prefered_name to app_name in the Builder struct and methods - Update PreferedName enum to include new variants and set AppName as default - Modify documentation to reflect the new app_name usage for auto start entry This refactor improves clarity in naming conventions and enhances the configuration options for auto start entries. * refactor(autostart): update app_name handling in README and lib.rs - Change app_name usage in README to a custom string - Simplify app_name handling in lib.rs by removing PreferedName enum - Update Builder struct to accept app_name as an optional string This refactor enhances the clarity and usability of the auto start configuration. * feat(autostart): add app_name builder method for custom application naming - Introduced a new builder method app_name() to customize the application name in the autostart entry. - Updated app_name handling in the Builder struct to accept a generic string type. This enhancement allows for greater flexibility in defining application names for autostart configurations. * Update .changes/autostart-feature.md Co-authored-by: Tony <68118705+Legend-Master@users.noreply.github.com> * [skip ci] format --------- Co-authored-by: Tony <68118705+Legend-Master@users.noreply.github.com>
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.
Note, that in this repository, even if only the Rust code or only the JavaScript code of a plugin changed, both packages need to be bumped with the same increment!
Use the following format:
---
"package-a": patch
"package-b": minor:feat
---
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).