Convention for releasing Rust packages after rawhide has branched

[the Mulhern]

Hi all,

Since last week, rawhide is now headed into f38, and f37 (which was
rawhide) is now its own branch.

What I'm trying to understand is what the appropriate conventions are
for releasing new versions of Rust libraries into Fedora.

Take for example, rust-ouroborous[1], which was released in four
places, rawhide (f38), f37, f36, and f35.

In contrast, rust-pretty-hex[2] is released only into rawhide (f38),
f37, and f36.

I think that the reason for the difference is that the new version of
rust-pretty-hex is is semantically incompatible with the previous
version, and that it was due to that that it was not released into
f35.

So, the rule I have come up with is that, after rawhide branches to
release n (currently f38), semantically incompatible updates of
libraries shall be released only to Fedora releases n, n - 1, and n -
2, but no further.

OTOH, semantically compatible updates of Rust libraries shall be
released to n, n - 1, n - 2, and n - 3 Fedora releases until n - 3
goes out of support, i.e., for another 2 months, approx.

Is that more or less the rule to follow?

Thanks,

- mulhern


[1] https://src.fedoraproject.org/rpms/rust-ouroboros
[2] https://src.fedoraproject.org/rpms/rust-pretty-hex


-- 
The Moving Finger writes; and, having writ,
Moves on: nor all thy Piety nor Wit
Shall lure it back to cancel half a Line,
Nor all thy Tears wash out a Word of it.
- "The Rubaiyat of Omar Khayyam", Robert Fitzgerald, translator

[Fabio Valentini]

On Mon, Aug 15, 2022 at 9:13 PM the Mulhern <amulhern(a)redhat.com&gt; wrote:
>  Hi all,
>
>  Since last week, rawhide is now headed into f38, and f37 (which was
>  rawhide) is now its own branch.
>
>  What I'm trying to understand is what the appropriate conventions are
>  for releasing new versions of Rust libraries into Fedora.
>
>  Take for example, rust-ouroborous[1], which was released in four
>  places, rawhide (f38), f37, f36, and f35.
>
>  In contrast, rust-pretty-hex[2] is released only into rawhide (f38),
>  f37, and f36. 
The pretty-hex update is actually an example of one of the exceptions
to the rule:
I try to update *all* Rust crates to the same version across all
Fedora branches.

The Change to package Rust crates on stable releases explicitly also
included an exception to the Updates Policy for this reason.

Sometimes updating crates to the same version across all branches is
not possible, because dependent packages don't have the same release
schedule and update policy.
For example, python-cryptography now has some Rust code in its
backend, and some crates need to be available in different versions
across different Fedora branches to keep it working. The same
reasoning applies to stratis - I need to make sure it keeps building
correctly across all Fedora branches, even though it's not the same
version that's being shipped across all branches.

On the other hand, there's stacks like gtk-rs / gstreamer-rs, for
which the latest update is only available on Fedora 36.
The latest version of the gstreamer crate depends on pretty-hex v0.3,
but the version of the gstreamer crate on Fedora 35 still requires
pretty-hex v0.2.
The gtk-rs / gstreamer-rs stacks are pretty big (i.e. dozens of
packages) and they need to be updated together.
The latest update also broke APIs and builds of applications which
used them, which is why I only pushed it to rawhide / branched (36) at
the time, but not Fedora 35.
This also affected some dependent packages (I think "system-deps" and
"version-compare" crates).

>  I think that the reason for the difference is that the new version
> of
>  rust-pretty-hex is is semantically incompatible with the previous
>  version, and that it was due to that that it was not released into
>  f35. 
SemVer-incompatible updates in themselves are not a reason to hold
back an update (Rust library crates are exempt from the Updates Policy
here), if you make sure dependent packages aren't broken - either by
porting dependent crates to the new version, or by adding a compat
package for the old version.

>  So, the rule I have come up with is that, after rawhide branches to
>  release n (currently f38), semantically incompatible updates of
>  libraries shall be released only to Fedora releases n, n - 1, and n -
>  2, but no further.
>
>  OTOH, semantically compatible updates of Rust libraries shall be
>  released to n, n - 1, n - 2, and n - 3 Fedora releases until n - 3
>  goes out of support, i.e., for another 2 months, approx. 
The rule for library crates is: Update them on all branches, when possible.

I have actually tried to harmonize a few exceptions here, for example,
the ouroboros crate is now at the same version (v0.15) across all
branches of Fedora, where previously, it was at v0.10 on Fedora 35 and
at version v0.13 on Fedora 36. Now the main rust-ouroboros package is
at v0.15 across all branches, and there are compat packages for
ouroboros v0.10 and v0.13 on Fedora 35 and 36, respectively - and I'll
be trying to make this more consistent for some other crate packages,
as well. Doing that will make building crates across Fedora branches
more predictable, I hope. So if a package builds on Rawhide, it should
also build without modifications on F36 and F35 (but not necessarily
the other way round).

On the other hand, it would be *way more difficult* to *not* push
SemVer breaking library crate updates to stable branches.
Doing things this way would basically prevent most crate updates
except on Rawhide (which is why the Rust library crates are exempt
from the Updates Policy).

Fabio