[Pkg-rust-maintainers] Bug#1013729: Bug#1013729: re: rust-zbus: Please upgrade to version 2.2.0

[Zeeshan Ali Khan]

Hi Peter,

On Thu, 17 Nov 2022 at 23:32, Peter Green <plugwash at debian.org> wrote:
>
> Zeeshan Ali Khan wrote:
> > zbus creator/maintainer here.
>
> Thanks for weighing in.

Np, thanks for your detailed response.

> > Why annoyingly? Where else should I provide the release notes? I take
> > the time to write proper release notes for each release so I'd
> > appreciate some appreciation for that. :) Most projects these days
> > don't bother at all and if they do, they just copy&paste the git log.
>
> Firstly it's a bit hidden, I suspect most people get their releases
> from crates.io,

Well IMO the best place to publish them would be on crates.io itself
when one does `cargo publish` but unfortunately that's not supported.
So folks do have to click on the repo.

> click on the link to the repository when they want to
> view what is going on with development and don't even realise that
> the releases tab on the gitlab project is being used.

That's to do with Gitlab not being super popular so folks don't know
where to click but once you've seen it, you know where they are.

> Secondly it throws multiple crates and multiple branches in together.

We've a mono repo so there has to be multiple crates, unfortunately. I
don't think we're alone on this one at all though. I don't think it's
very hard to search in there for particular releases.

Not sure what you mean by branches. They're just releases. We only
support the latest release cycle so there aren't really any branches.

> this can mean looking through quite a lot of entries to find the one
> you want.

You may have a point here but I understood you were looking for
entries for particular releases and I don't think that's hard to find.

> When packages bother to maintain a changelog (which sadly most don't)
> the convention in the rust community seems to be a file called
> CHANGELOG.md in the root of the source tree.

Don't you think all the problems you mentioned above about difficulty
searching for particular entries, would apply here as well?

The CHANGELOG.md is typically just a copy&paste of the git log. I
never understood the point of re-adding git log into a file tracked by
git. It does have the advantage of easy discoverability because the
practice is quite common.

FWIW, I have also recently started to include release notes in release
tags annotations.

>  > Indeed. I strongly suggest bumping directly to the latest v3.
>
> If v2 to v3 is a trivial change, then I think it does indeed make
> sense to skip v2.

>From a user (dependent apps/crates) perspective, it's quite trivial.
Internally, it was a big effort (not as big as v2 though). Only reason
to bump the major version was some API breakage that could affect some
folks.

> That still leaves the question of what to do about v1 to v2.

I'd just ignore v2. If you port to v2, most likely porting to v3 would
be trivial.

> My
> experience trying to port libslirp was that it was not a trivial
> task. I didn't try to port squeekboard, so maybe it was something
> weird about how libslirp uses the crate.

I'm not familiar with libslirp. v2 is a big change since we almost
re-wrote the core and the API is now primarily async.

> I went through serveral pages of releases and found the release
> notes for version 2.0 but they didn't really enlighten me.

If I had the time, I would have provided a porting guide. :( I think
the main way to get into the API is the book. Comparing it to the v1,
is as close as to a porting guide you can get I guess:

https://dbus.pages.freedesktop.org/zbus/
https://dbus.pages.freedesktop.org/zbus/1.0/

>  > or if there's anything I can do to help.
>
> What would be helpful is persuading/helping upstreams of projects
> that use zbus and are currently in Debian to move to the latest
> version of zbus. Mainly libslirp and squeekboard.

Right, I can give it a shot but an important point to keep in mind
here is that this can easily become a chicken&egg issue. E.g I've been
actively pushing for an upgrade to zbus 3 in the netavark project but
they can't merge until zbus3 is packaged for Ubuntu. Incidentally,
that's how I end up here:
https://github.com/containers/netavark/pull/412

So keeping that in mind and also the fact that v2 and v3 are a
completely different thing than v1, perhaps v3 could be packaged
separately?




--
Regards,

Zeeshan Ali Khan