cargo-release VS toml-rs

My problem with maintaining a changelog during development is it can serve as a source of merge conflicts. Instead, I follow Covnentional Commit style and manually write my changelog entries based on the commits. I have a tool [0] that can show me the relevant commits for a package in my repo and automates the entire release process, including doing sanity checks.

I also feel like releasing from CI is hard, especially if you have multiple packages in a repo [1], including

- You can't as easily introspect the process

- You can't as easily recover from failure

- Getting a lot of the nuance right, like handling releases concurrent to merging of PRs, is difficult

- When the workflow is an ever-present "release PR" that you merge when ready has issues with selecting which packages to release and at what version

I have been considering making a tool to generate changelogs from fragments. Been keeping notes at https://github.com/epage/epage.github.io/issues/23

[0]: https://github.com/crate-ci/cargo-release

[1]: https://github.com/MarcoIeni/release-plz/discussions/1019

You should combine step 1 and 2 with CI. Just tag a version in your git, push to remote and have CI auto build a release for you.

Use github actions or other setup for other backends.

Or go nuts with cargo-release.

https://github.com/crate-ci/cargo-release

https://github.com/cargo-bins/release-pr

tools like cargo-release

Just to check, are you aware of cargo-edit's cargo-set-version or cargo-release?

I released my first crate that provides a derive macro to easily obtain a name of a current variant in an enum as a string. I did it mostly to learn about procedural macros and the process of releasing a crate. I then found out there is strum which does this and much more. Nonetheless, I learned a lot and I found couple of nice tools like ```cargo-release and git-cliff.

I'll note there is an issue in the cargo-release repo where this kind of workflow is wanted. https://github.com/crate-ci/cargo-release/issues/119

cargo-release is on about the same level of features used

cargo-release automates the release process for your crate. For example, with clap, all I do is add entries to the CHANGELOG and run cargo release patch and cargo-release takes care of updating files, publishing to crates.io, tagging, and pushing.

Yes, developers from all three tools were sharing ideas with each other recently

I updated the toml<->json online converter after the ValueAfterTable error has been fixed with toml 0.6. Very nice to see progress on the toml and toml_edit crates.

use std::fs::File; use std::io::Write; use std::collections::BTreeMap as Map; use serde_derive::{Serialize, Deserialize}; #[derive(Debug)] #[derive(Serialize, Deserialize)] #[serde(tag = "type0")] enum FooBarTwo<'a> { FooBarOne { string1: &'a str }, } #[derive(Debug)] #[derive(Serialize, Deserialize)] #[serde(tag = "type1")] enum FooBarThree<'a> { FooBarFour { string2: &'a str }, } #[derive(Debug)] #[derive(Serialize, Deserialize)] struct FooBarFour<'a> { black: &'a str, #[serde(borrow)] green: FooBarTwo<'a>, #[serde(borrow)] blue: FooBarThree<'a>, } #[derive(Debug)] #[derive(Serialize, Deserialize)] struct FooBarFourList<'a> { // Uasing a Map to workaround a known bug (#303) when using top level Vec // see https://github.com/alexcrichton/toml-rs/issues/303 #[serde(borrow)] foo_bar_six: Map<&'a str, FooBarFour<'a>> } fn main() { let red = FooBarFour { black: "aaa", green: FooBarTwo::FooBarOne { string1: "aaaabbbb" }, blue: FooBarThree::FooBarFour { string2: "ccccccc" }, }; let pink = FooBarFour { black: "aaa", green: FooBarTwo::FooBarOne { string1: "aaaabbbb" }, blue: FooBarThree::FooBarFour { string2: "ccccccc" }, }; let mut white = Map::new(); white.insert("pink", pink); white.insert("red", red); let fbfl = FooBarFourList { foo_bar_six: white }; println!("\nTL: {:?}\n", fbfl); let filename = "./data/test.toml"; let data = toml::to_string(&fbfl).expect("Error serialising fbfl"); println!("\nTL as TOML: {:?}\n", data); let mut f = File::create(filename).expect("Unable to create file"); f.write_all(data.as_bytes()).expect("Error writing data to file"); let toml_in: FooBarFour = toml::from_str(&data).expect("Error deserialising fbfl"); println!("\n{:?}\n", toml_in); }

This is especially useful for data deserialization: Just by implementing the Serialize and Deserialize traits from the serde crate, the (almost) universally used serialization library in the Rust world, we can then serialize and deserialize our types to a lot of data formats: JSON, YAML, TOML, BSON and so on...

It looks like the fields are public now (https://github.com/alexcrichton/toml-rs/pull/455, https://docs.rs/toml/latest/toml/value/struct.Date.html), so just upgrading the crate should do it :-)

Pair that with Serde for serialization/deserialization (JSON, TOML, YAML, CSV/TSV, XML, URL query strings, etc.), Figment for configuration, and ignore for filesystem traversal with blacklist support, and Rust is a real joy for writing CLI utilities.

Added toml-rs-compatible API via the toml_edit::easy module for when developers want to ensure consistency between format-preserving and general TOML work, with one caveat.

A quick example off the top of the head of my head is some tests in the toml package. It has a few different approaches. One is to use macros as in parser.rs. In valid.rs and invalid.rs it uses macros to generate a separate test for each input file. This allows you to run just one individual test from the list. These examples aren't perfect, and there are more sophisticated test utilities (like insta) that can abstract the process of "here are a bunch of inputs, test them all".

I want to read a toml file with default value. I tried toml-rs but it doesn't allow for default values.