Proposal: 0.8.7 patch release backporting #4161 (libsqlite3-sys relaxation)

[secana]

Filed alongside #4240 (0.9.0 release cadence). This is an alternative/complementary path to unblock the ecosystem sooner.

Proposal

Cut a 0.8.7 patch release containing a single-line backport of merged PR #4161: relax libsqlite3-sys in sqlx-sqlite/Cargo.toml from "0.30.1" to ">=0.30.0, <0.37.0" on the 0.8.x line.

Why

• sea-orm (all rc versions through 2.0.0-rc.38) pins sqlx = "^0.8.4" and cannot adopt 0.9 until both sqlx 0.9 is released and sea-orm bumps. That's a multi-hop wait blocking every downstream of sea-orm that also depends on rusqlite/cargo (see Conflict of libsqlite3-sys (via sqlx-sqlite) with newer rusqlite in downstream workspaces SeaQL/sea-orm#2725).
• The underlying fix in sqlx-sqlite: relax libsqlite3-sys constraint to allow 0.36.x #4161 is literally a one-line constraint change. No other sqlx-sqlite source file needs to change for 0.8.x to compile against libsqlite3-sys up to 0.36.
• Verified: I applied this exact change on top of v0.8.6 and built downstream (including sqlx-sqlite + cargo 0.96.0 → rusqlite 0.38 → libsqlite3-sys 0.36.x) successfully, end-to-end.

Ready-to-cherry-pick commit

kellnr/sqlx@8f6b2fb (on branch v0.8.6-libsqlite3-sys-relax, based on v0.8.6 tag). A mirror is also on secana/sqlx backport/relax-libsqlite3-sys-on-0.8. Happy to open a PR against a release/0.8 branch if maintainers create one.

Asks

1. Would you accept this as a 0.8.7 patch?
2. If yes, can a release/0.8 branch be created so I can open a proper PR?
3. If no (0.8 is EOL after 0.9 alpha): closing is fine — Tracking: release cadence for 0.9.0 #4240 is then the main path.

[zefr0x]

The underlying fix in sqlx-sqlite: relax libsqlite3-sys constraint to allow 0.36.x #4161 is literally a one-line constraint change. No other sqlx-sqlite source file needs to change for 0.8.x to compile against libsqlite3-sys up to 0.36.

The fix started with #3928 not #4161, and I'm not sure if it was a one line change (there was other changes in the PR and I can't be sure that nothing is related).

[secana]

You are right, #3928 is where the version-range policy originated, and it's a big PR.

Looking at it, it seems that #3928 landed on the unreleased/0.9 line, so on v0.8.6 the constraint is still libsqlite3-sys = "0.30.1" (exact pin) and none of #3928 is present. The backport I'm proposing against 0.8.x is
just the single-line relaxation of that pin. The full diff on top of v0.8.6 is:

[dependencies.libsqlite3-sys]
-version = "0.30.1"
+version = ">=0.30.0, <0.37.0"

See kellnr/sqlx@8f6b2fb — only sqlx-sqlite/Cargo.toml is touched.

I tested it by pointing a downstream build at that branch (sqlx-sqlite → rusqlite 0.38 → libsqlite3-sys 0.36.x, alongside cargo 0.96.0) and it compiled and ran end-to-end without any other source changes. So at
least in that configuration it seems like nothing else from #3928 is required on 0.8.x, but I'd very much welcome anyone double-checking by building against the branch. It's entirely possible I missed something a maintainer would catch.

[pronebird]

Personally I'd like to see #3952 in 0.8.7.

[abonander]

I don't like to backport fixes because I don't have the bandwidth to maintain multiple releases concurrently. If I backport one fix, people will start requesting backports for others. I'd rather just have everyone upgrade to the latest release if they can.

FWIW 0.9.0 is out now: #4271