3 releases
0.1.19 | Feb 13, 2023 |
---|---|
0.1.19-beta.40 | Feb 8, 2023 |
0.1.19-beta.35 | Feb 1, 2023 |
#757 in #enums
23 downloads per month
Used in 3 crates
(via tpfs_logger_port)
9KB
82 lines
Table of Contents generated with DocToc
Tpfs Log Event Procmacro
This crate is used to help implement the tpfs-logger-port::LogKVPair
trait by converting enums in to the LogKVPair with
the use of an attribute macro.
Faster Check of Source Code without Compiling
cargo check
Running Build and Tests
cargo make build
cargo make test
Running Linting
cargo make lint
Running Auditing
cargo make audit
Publishing of Prerelease Crates
Please see the versioning guidelines to understand prereleases: https://gitlab.com/TransparentIncDevelopment/docs/engineering-guide/blob/versioning-proposal/versioning.md
You should use prereleases to test out a concept in a different crate. However this is not intended for your final releases. See Publishing changes to a crate for finalizing.
You can manually push a prerelease version for a branch by finding the corresponding pipeline in gitlab and clicking the play button next to the manual-publish-prerelease-crate
job.
Prerelease crates will also be automatically published as merges occur to master.
Publishing a version change to a crate
The versioning of the crate should be maintained via semantic versioning and there are helper scripts to help update the version in the Cargo.toml and Cargo.lock files. This version change can happen on your branch hopefully right before the MR is approved to be merged.
Use one of the following:
cargo make publish-patch
cargo make publish-minor
cargo make publish-major
In order to actually publish the change this should be done after an MR has merged to master. Once merged pull from master and rebase then tag a release using the script helper.
It would look like the following:
git checkout master
git pull
cargo make tag-release
git push --tags
Understanding Semantic Versioning
We have something written up in our engineering guidelines: https://gitlab.com/TransparentIncDevelopment/docs/engineering-guide/blob/versioning-proposal/versioning.md
The basics of semver is if the only changes included are fixes and adjustments then it's just a patch version number bump. Then if there are additions to functionality it's a minor version bump, and if it's a breaking change then it's a major number bump. The precendence is set at if there's a major version bump for a breaking change it would encompass any additional functionality without needed to bump the minor version. The same is true for minor version bumps that take priority over a patch version bump.
An example of that would be if the version number is 1.0.0
and there was additional functionality along with some fixes this would update the version to 1.1.0
.
Dependencies
~0.6–1MB
~23K SLoC