Elijah Newren <newren@xxxxxxxxx> writes: >> The fast-export stream produced by the code with d9cb0e6f >> (fast-export, fast-import: add support for signed-commits, >> 2025-03-10) used to identify a signature algorithm "sha1", but this >> new version of fast-import lost the support for it, and will barf >> when seeing such an existing fast-export stream? I am not sure what >> is going on around this code. >> >> I am not so worried about the other case, where the stream produced >> by fast-export contained in this version may or may not be readable >> by an older version of fast-import. > > I certainly can't answer anything here as I know little about > signatures, but your comment brought up a different question for me: > Given that d9cb0e6ff8b3 (fast-export, fast-import: add support for > signed-commits, 2025-03-10) isn't part of any release (not even a > release candidate), do we need to have backward compatibility with > that version? I think we will lose all the credibility if we said "that's not in an official release, so we are free to break early adopters", once something is in 'master'. As some corp environment are know to run 'next' and indeed we do encourage more folks to do so so that we can catch breakages before they escape to 'master', I actually am equally worried about things in 'next'.
