Mingun
commented
4 months ago 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.
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).