Publishing releases automatically

[rambip]

I have added my crates.io API key inside github secrets, with the name CARGO_REGISTRY_TOKEN.

The next step is to use cargo publish inside github actions in order to update the published crates on crates.io

The project is becoming pretty stable, so being able to install it without friction is valuable for users.

Currently, the published crates are:

• dioxus-markdown
• yew-markdown

leptos-markdown already exists (link), I tried to contact the owner a few years ago but he did not respond.

If we want automatic releases, it would be nice to have release notes each time there is an important new feature, and a regular schedule (something like every 2 weeks) for minor bug fixes.

@Craig-Macomber does that sound right to you ?

PS: is there a way to bump automatically the version in Cargo.toml ? Last time I worked with crates I had to publish, I often forgot to increase the version in the files. I guess they are bots for that ?

[Craig-Macomber]

I've just been pulling in the packages via git, so I hadn't been thinking about proper releases. All the stuff I knew I wanted to change for now is done, so I'm not sure how often there will be changes will be going forward. If I hit more issues or limitation though I'll be trying to fix them.

Anyway, since the other packages depend on web-framework-markdown I imagine that needs to be published as well.

I personally haven't ever setup automated publishing on git-hub (or done anything on it using secrets), and its probably been a couple years since I actually published a crate by hand either, so I don't have any insights on how to do that. What you are planing seems like a good approach to me, but I don't actually know the best practices here.

For making what the changes are clear, we probably want a change log listing the changes in each release, and make sure its up to date when we bump the version, and ensure the version bump we do follows semver based on what the changes are. There are tools to help automate that, but at our scale I think they are more trouble than they are worth (And I haven't used one I really like, so I don't have a good recommendation).

When I have a bit more time (in a few days probably), and have used the latest version a bit more so I'm more confident I didn't break anything it in, I'll try and fix the versions, and write up some change-logs so we can get them published.

[Craig-Macomber]

One minor thing I'll note: if we want to follow SemVer, and also try to limit breaking changes / major version bumps, there are some details of the API we should cleanup, but that in itself will be a breaking change.

Things like some structs, like MdComponentProps having public fields makes pretty much any change to them a breaking change. Making those fields non-public and only exposing them via methods would make having a stable API and avoiding breaking changes much more practical. I have a lot of experience doing this kind of thing (though not much in Rust recently), and could make a pass over the API surface cleaning things up so we can more easily maintain compatibility going forward.

[rambip]

One minor thing I'll note: if we want to follow SemVer, and also try to limit breaking changes / major version bumps, there are some details of the API we should cleanup, but that in itself will be a breaking change.

Things like some structs, like MdComponentProps having public fields makes pretty much any change to them a breaking change. Making those fields non-public and only exposing them via methods would make having a stable API and avoiding breaking changes much more practical. I have a lot of experience doing this kind of thing (though not much in Rust recently), and could make a pass over the API surface cleaning things up so we can more easily maintain compatibility going forward.

The API standardization step would be really nice, in particular if you say you have experience in this kind of thing.
For the other points, I agree on each one of them.
The vanilla github action that runs cargo publish is probably enough, and if we forget to bump a version it will just produce a failed run in the CI.

[Craig-Macomber]

I made a pass through he API surface making a few minor tweaks, but mostly documentation fixes and adding change-logs in #30 and #31. With that done, I think it would make sense to publish a new version.

There is still more cleanup of the APIs we might want to do, but I don't see anything else that's either trivial to do or important. The API was actually in better shape than I thought.

I mainly looked at the web-framework-markdown package: there might be more to do in the others.

[rambip]

Cool !
I don't know about the API expectations for leptos, dioxus and yew. I will try to take a look at it in the near future.

[hadeutscher]

Hey! Really cool crate. Can you publish dioxus-markdown manually for now? I'm trying to use it with Dioxus 0.7 and have to source it from git (because the version on crates.io is still 0.0.1 which uses Dioxus 0.6)