Should commits adapting to breaking changes in outside dependencies be conventional?

[EliahKagan]

When one gitoxide-related crate depends on another gitoxide-crate and has to be changed to adapt to a breaking change in its dependency, we don't use a conventional commit, unless there is an unusual special reason users would need to know about it.

Does that apply also to changes in gitoxide-related crates that depend on something that isn't related to gitoxide and isn't developed as part of this project? For example, suppose windows-sys changes, such that an argument that we were passing as 0 must instead be passed as std::ptr::null_mut(). This is not very interesting for anybody who isn't working on that code, but if someone is looking for it, they may be less likely to find it since there isn't a separate changelog entry for any gitoxide-related crate that points to it directly.

Based on the above discussion and the general policy, I think the answer is that such fixes should still not be documented with conventional commits, and that the changed supported dependency version range (which is made clear even in the absence of any conventional commit anywhere) is everything users need. But I figured I'd check.

[Byron]

Thanks for asking!

I thought about it again and once more came up with "if users don't need to know about the change, there shouldn't be a conventional changelog entry".

However, I might be missing a concern you were having that triggered the creation of the issue in the first place. Ultimately, the changelogs should be useful, and maybe they can be more useful with adjustments to the guideline?

[EliahKagan]

However, I might be missing a concern you were having that triggered the creation of the issue in the first place.

No, I think you're probably not missing anything. Thanks for bearing with the lack of context in this question. I had a few motivations in asking this, none of which would motivate any adjustments to the guidelines as far as I know:

• I don't remember why I had originally put fix: on the commit in #1815 that adapted gix-lock to changes in gix-utils. I think the reason was just that it was split out of a fix!: commit and seemed conceptually to be part of the fix. Since I remembered I wasn't sure what to do but didn't entirely remember why, I figured I should ask for clarification in case the situation were different.
• In that situation, there was a conventional commit (and thus a changelog entry somewhere) in this repository, since the change was in another crate. But I don't know how that would matter.
• I am used to working with forms of dependency management that work differently, where indirect dependency versions are imposed on all components, i.e., where dependencies are "flattened." So I have some intuitions about things that could be breaking changes or otherwise be of interest to users that do not hold for Rust.

Ultimately, the changelogs should be useful, and maybe they can be more useful with adjustments to the guideline?

Although I don't think my motivation for asking this directly raises any changes, revisiting #1815 seems to reveal one. bf4fa1b should actually have been a doc: (or docs:) commit, because Fail is public and it would benefit users of the crate to be informed that the previous documented claim was inaccurate:

gitoxide/gix-lock/src/acquire.rs

Line 17 in f1bb269

/// Retry after failure with quadratically longer sleep times to block the current thread.

But I don't know if that's a change to the guidelines, so much as a separate reason to use a conventional commit that would already have been recognized, just I didn't notice that it should be done.

---

There is a separate recent case that might have called for conventional commits where I didn't use them: sometimes a crate republishes a dependency, or some part of it. I'll look into whether that might've happened in #1949. But either way I think it is separate from the question asked here.

Edit: I've opened #1952 for this.

[Byron]

Alright - in cases were you think you missed it, I must have missed it to, so I assume it wasn't clear-cut. Generally, changes should go into Changelogs if they are relevant to the users of an API. Sometimes a single commit message can be relevant in multiple crates, but often they are not, or there is benefit in having one commit for each crate.
That's the one rule I go by, and one from which certain patterns are derived.