add publish-crates workflow

[jbr]

This pr locks versions between the cli, the client, and the api, but that may not be desirable. I'd appreciate review on whether we should have distinct semver-meaningful versions for each crate or whether we want to bump everything all at once like janus. Also, we may want to have a discussion about what merits a semver-minor change, since we recently quietly introduced a breaking change to the api

[branlwyd]

Thoughts on versioning: I'm fine keeping the two crates in-sync in terms of version; as long as we're using 0.0.x versions we don't have any backwards-compatibility concerns (that is, every version is expected to be compatible only with itself).

We will need to provide better backcompat guarantees eventually, and we should do so by switching to (at least) a 0.x.y version. For now, I think we can stay with a 0.0.x version.

[branlwyd]

super-nit: missing trailing newline

[jbr]

My concern with 0.0.x is specifically for divviup-client, since cargo will auto update to the latest patch version, which will include breaking change versions as well as nonbreaking changes. It might make more sense to use 0.x.0 if we're only going to do one version number?

[branlwyd]

👍🏻 Going to 0.1.0 sounds good to me.

[tgeoghegan]

Yes, let's go to 0.1.0. Also, I like keeping the various crate versions in sync, because then it's very easy to tell people to use client or CLI version 0.x.y if they want to talk to a server running version 0.x.y and get a guarantee they speak the same version (in case we do mess up with semver).

[tgeoghegan]

re: SemVer: Over in Janus, we've been trying to respect SemVer for Rust API changes, but also when we change DAP versions, since that breaks compatibility with other DAP participants. So I think we could also bump the minor (middle) version here when we know we've broken the HTTP API.

[jbr]

we also have our content type version, maybe we should use the semver-minor as the content type version, and bump both of those on breaking api change?

[tgeoghegan]

That seems fine to me, though we'd also have to look into actually doing something with the content types.

[jbr]

That seems fine to me, though we'd also have to look into actually doing something with the content types.

We do enforce that the content types are identical, which provides a compatibility check at the api boundary. At some later point, individual endpoints could annotate which version ranges they support and/or switch implementations based on content type / eaccept. Erring in the direction of a stricter api compatibility contract seems preferable early-on while it's feasible to keep clients upgrading. Later, if it's difficult to keep clients upgrading at the pace of breaking api changes, there are options.

[tgeoghegan]

Should we take this before releasing 0.0.31 and deploying it this week? I'll need to rebase #611 but that's no big deal.

[divergentdave]

We'll still need to specify a version on these dependencies, in addition to specifying a path, in order to publish certain crates. Currently, cargo publish --dry-run -p divviup-cli fails because its divviup-client dependency doesn't specify a version.

[jbr]

drat, I was hoping more of https://rust-lang.github.io/rfcs/2906-cargo-workspace-deduplicate.html had been implemented than was

[jbr]

maybe we should do a publish dry run in ci?

[divergentdave]

One barrier we've run into with Janus is that, since we're publishing two crates consecutively from the same workflow, there are some changes where the dry run for the second crate can't pass if the new version of the first crate hasn't been released.

[divergentdave]

I got cargo publish --dry-run -p divviup-client to work with the following changes.

diff --git a/Cargo.toml b/Cargo.toml
index 6ae9c44..b1782a3 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -11,8 +11,8 @@ repository = "https://github.com/divviup/divviup-api"
 [workspace.dependencies]
 divviup-client = { path = "./client", version = "0.0.30" }
 divviup-cli = { path = "./cli", version = "0.0.30" }
-divviup-api = { path = ".", version = "0.0.30" }
-test-support = { path = "./test-support", version = "0.0.30" }
+divviup-api.path = "."
+test-support.path = "./test-support"
 
 [package]
 name = "divviup-api"
diff --git a/client/Cargo.toml b/client/Cargo.toml
index 8f8c250..3eca422 100644
--- a/client/Cargo.toml
+++ b/client/Cargo.toml
@@ -36,4 +36,4 @@ trillium-macros = "0.0.4"
 trillium-testing = { version = "0.5.0", features = ["tokio"] }
 trillium-rustls = "0.4.0"
 trillium-tokio = "0.3.2"
-divviup-client =  { workspace = true, features = ["admin"] }
+divviup-client =  { path = ".", features = ["admin"] }

Including a version in addition to a path on private crates was a problem, because Cargo was still trying to look them up in the index. Only when a dev-dependency has just a path will Cargo prune it before publishing. Then, the self-dev-dependency that divviup-client had needed to drop the version for a similar reason, since the version it specified necessarily hadn't been uploaded yet.