high frequency of API-breaking releases

[decathorpe]

Just within the last month, there have been 5 new releases of quick-xml, all semver-breaking. Looking at the reverse dependencies on crates.io, it is pretty obvious that most crates are still using versions that are much older than that: https://crates.io/crates/quick-xml/reverse_dependencies

The frequency of releases that break API and / or behaviour is starting to be problematic for developers who rely on this crate. It's hard to keep up with changes. And if you stick with an older version, it can introduce other problems, like resulting in multiple versions of quick-xml being present in larger dependency trees.

I am affected by this in two ways:

• I maintain an XML-RPC framework written in Rust dxr that uses quick-xml for de/serializing XML. It's working great, but moving to new versions of quick-xml is always very painful. This is why dxr is still stuck at ^0.30 - I just couldn't figure out how to adapt to newer versions of quick-xml.

• I maintain packages of quick-xml for Fedora Linux. We try to keep the number of versions that we need to support to a minimum. But when there's a lot of incompatible-with-each-other releases like here, that is pretty painful to deal with. Especially because some dependent libraries move to the latest quick-xml release quickly, while other projects move more slowly (if at all).

[Mingun]

I regret that the frequency of releases creates difficulties in some cases, but this is a necessary evil. It is better to evolve to beautiful API when we can instead of have troubles later. Fortunately, we are already very close to version 1.0 where we will be much more stable. There may be no more releases before the serious rewrite (#766 and a couple of planned PRs) that is currently underway, but this release will indeed be very breaking, but it will bring many new features.

Actually, last releases contains not so many breaking changes and I think that most projects could use range dependencies. Many breakage from changing Error type, but in most cases it is used transparently anyway. If you use serde, then the compatibility is even more wide, I think, you can absolutely safely use >=0.31,<0.36 and even wider.

BTW, if you'll have difficulties when updating quick-xml related code, you can tag me and I try to help. Anyway, thanks to pointing out to this problem.

[Mingun]

I see that dxr uses serde API. Since version 0.30.0 there are no changes in serde (de)serializer (and not planned even after rewrite), so it should be safe to update. In any case, if you find some case when something worked unexpectedly or not flexible enough, fill an issue (and maybe PR 😇)

[decathorpe]

Thank you! Having a "stable" release on the horizon is really good news! I looked at open issues and projects but couldn't find any references to "this is needed before we publish 1.0.0", so maybe it would be good to mark these issues in a more obvious way so you won't get more unnecessary tickets like mine? 😅

Side note: Yes, dxr does use the serde interface, but with some custom deserialization logic sprinkled in ... and I think that's where our trouble comes from :(