Stefan Sperling wrote on Wed, 28 Aug 2019 12:07 +00:00: > Also, users would have a much harder time trying to verify what they > are actually running.
Did you see the part where I specifically proposed to release a patch that fixes the issue _and_ bumps SVN_VER_PATCH? (The patch can also add a new hunk to the top of CHANGES.) > I believe this approach would make things harder for downstream consumers. > They would need to track new Subversion releases as well as patches, so we > would be shifting more work onto them. This would be unfair on our part, > even given our current predicaments. We should not be offloading our own > release engineering work onto other projects. > > Downstream processes are optimized towards the general case across the > software ecosystem, which is updating to a new release which contains > a bunch of fixes. > So I would prefer a new release, together with an updated CHANGES file > which documents the problems we fixed. Even if it's a few weeks late. > That way, downstreams won't have to adjust their existing process. I expect most if not all downstreams are perfectly capable of cherry-picking a single patch from upstream onto their package. In Debian that's as easy as upgrading to a new upstream tarball (there are automations for both of these tasks). I do concede that if we had just a single release format, tarballs, that'd be easier on downstreams, but I do not accept that releasing patches would place an unreasonable burden on downstreams. Come to think of it, this is exactly what we _already do_ for people on the pre-notifications list: we don't send them tarballs, but patches. Actually, I remember that we _used_ to send them tarballs, to password-protected download pages, but we switched from that to just sending signed advisories, and I don't recall any complaints about that.
