adds pipeline to bump semver and release to crates.io automatically

[alexanderjophus]

I can't figure out how to mark this as a draft myself, but I want to check a few things before this is actually ready.

This change introduces a new pipeline for the maintainers to release dioxus in a simple manner.

Things to note:

• The following diff is necessary, this defaults to the code in the workspace enabling maintainers/contributors to easily and quickly write code across different crates. The version should be maintained by a bot and automatically bumped as/when a new version is released, it is required for cargo workspaces to work (as it depends on crates.io's requirements of there being a version number)

+ dioxus-rsx = { workspace = true, version = "0.4.2" }
- dioxus-rsx = { workspace = true }

• I'm still trying to figure out how to solve for unreleased packages such as signals and generational-box. I believe cargo workspaces allows you to specify which packages to release but this is not implemented yet. As such, the PR as it stands would bump everything to 0.4.3 on the next patch regardless of if it's 0.4.2 now or 0.0.0.

Fixes part of https://github.com/DioxusLabs/dioxus/issues/1539

Example commit in the much simpler slides project I'm working on. Note how it maintains the version in all the packages.

[alexanderjophus]

After a discussion with Marc on discord, we're going to try pinning to 0.4 to see what happens, otherwise it may publish unnecessary versions a lot.

[alexanderjophus]

Looks like pinning to 0.4 will also work and is possibly preferable.

Proof: https://github.com/alexanderjophus/dioxus-slides/actions/runs/6840221582/job/18599245617

[alexanderjophus]

Noticed there's a possible hiccup with this when running some examples.

My terminal gets littered with these - exploring options now:

warning: /Users/ajt/projects/tmp/dioxus/packages/dioxus-tui/Cargo.toml: unused manifest key: dependencies.dioxus-core.version

[ealmloff]

Noticed there's a possible hiccup with this when running some examples.

My terminal gets littered with these - exploring options now:

warning: /Users/ajt/projects/tmp/dioxus/packages/dioxus-tui/Cargo.toml: unused manifest key: dependencies.dioxus-core.version

dioxus-tui might not use dioxus-core anymore (instead it just uses dioxus). You could try entirely removing the dependency

[alexanderjophus]

The only fix I've found is the following in the package cargo.toml files.

+ dioxus = { path = "../dioxus", version = "0.4" }
- dioxus = { workspace = true, version = "0.4" }

I tried various permutations in the root Cargo.toml file, most googling suggests .cargo/config.toml, which showed no luck either.

Question for yourself is; is that ok?

[ealmloff]

The only fix I've found is the following in the package cargo.toml files.

+ dioxus = { path = "../dioxus", version = "0.4" }
- dioxus = { workspace = true, version = "0.4" }

I tried various permutations in the root Cargo.toml file, most googling suggests .cargo/config.toml, which showed no luck either.

Question for yourself is; is that ok?

That wouldn't be great. using workspace dependancies makes it much easier to move around, rename and add new crates. What exactly caused the error? Did adding the versions cause the error? Is it an issue in cargo workspace? It seems like this might be related to https://github.com/pksunkara/cargo-workspaces/pull/56. In the discussion, there is a fork linked that fixed this issue. Maybe we could try that fork

[alexanderjophus]

Not sure I have the bandwidth to finish this. I do agree that we should stick with the workspace = true setting.

As far as I know that ticket you linked is not related (could be wrong though), but I do think the issue is in cargo workspace, I've just not dug through to find out more.

[jkelleyrtp]

Hey! Thanks for getting this off the ground. This is exactly what we need. I'll work on bringing it up to speed.

A few things, now that I'm looking at the PR:

• We can set publish = false for crates we don't want bumped
• Since we use workspace versions, we get huge jumps in crate versioning already. Hard to fix with how we do versioning. We really need to get to 1.x.x to use the actual flexibility of semver here.