Is it a breaking change to re-export a breaking change?

[EliahKagan]

When a crate re-exports another crate, and the re-exported crate version is bumped with a breaking change, is that considered a breaking change in the crate that re-exports it?

It seems to me that this must be a breaking change unless:

• The crate that re-exports it had already documented that this part of its interface has reduces interface consistency guarantees, or
• The breaking change applies only to features of the crate being re-exported that are never enabled by (and can never be enabled through) the crate re-exporting it.

The concrete recent case that motivates this is that gix-features re-exports bytesize and prodash.

We have just done a major version bump of bytesize in #1949. Furthermore, releasing a new version of prodash that itself bumps its own bytesize dependency (and using it in gitoxide) is under consideration, as discussed in #1947 (comment). More specifically:

• The gix_features::progress module is itself public in gix-features:

  gitoxide/gix-features/src/lib.rs

  Lines 27 to 28 in f1bb269

  	#[cfg(feature = "progress")]
  	pub mod progress;

• gix_features::progress re-exports bytesize:

  gitoxide/gix-features/src/progress.rs

  Lines 4 to 5 in f1bb269

  	#[cfg(feature = "progress-unit-bytes")]
  	pub use bytesize;

  (Other than in that configuration, this stub-like module is defined instead.)

• prodash is republished in full as well:

  gitoxide/gix-features/src/progress.rs

  Lines 6 to 7 in f1bb269

  	pub use prodash::{
  	self,

On the other hand, one might argue that the specific contents of gix-features are effectively not meant to be part of its public interface, but only of a cross-crate internal-ish interface to other gitoxide crates. But if that is the case, then I think it should be documented explicitly for gix-features. I am also not sure that this would affect what ought to be considered a breaking change for gix-features: if only gitoxide creates are meant to use some parts of gix-features, that's still a breaking change from the perspective of a separate crate using gix-features.

If I am correct to think upgrading the re-exported bytesize was a silent (unnoted) breaking change, but if prodash is going to release a new version that bumps its own bytesize dependency from major version 1 to 2, then the lack of a conventional commit identifying this as a breaking change (or at least as a feature change?) could be corrected there when we bump the prodash dependency version.

(This is the separate follow-up question to #1946.)

[Byron]

This is a great catch!

Yes, this should be a breaking change for gix-features, and I was unaware. This would mean gix-features should explicitly upgrade prodash and declare it a breaking change.

Failing to do so may mean breakage downstream upon release, and it's always a hassle to deal with the fallout (which probably would be small here as prodash and bytesize are probably not used very much if at all.

[EliahKagan]

Yes, this should be a breaking change for gix-features, and I was unaware. This would mean gix-features should explicitly upgrade prodash and declare it a breaking change.

Even though I had suggested this, I then did not do it in #1953, because the prodash version bump was in a patch version so it didn't seem like it would fit.

The problem, as I understand it, is mainly in bytesize rather than prodash. That is, the earlier upgrade of bytesize in #1949 was a breaking change for gix-features and therefore should've had a fix!: or feat!: conventional commit for it, to ensure that the version number advances properly.
 

Failing to do so may mean breakage downstream upon release, and it's always a hassle to deal with the fallout (which probably would be small here as prodash and bytesize are probably not used very much if at all.

In spite of the opportunities I've missed to do it so far, I'm hoping there is some reasonable way to mark this breaking (at least to ensure that version numbers of released crates reflect it). Please let me know.

[Byron]

In spite of the opportunities I've missed to do it so far, I'm hoping there is some reasonable way to mark this breaking (at least to ensure that version numbers of released crates reflect it). Please let me know.

Absolutely. In spite of a commit that would indicate breakage, one can always manually increment the crate's version number in the cargo manifest. This will also do the right thing when using CSR.

[EliahKagan]

Thanks--that sounds like the way to go, if feasible.

I don't know if it's possible or a good idea to do this now rather than right before a release when it would be more expected yet also very easy to forget. (This is relevant if the next release of gix-features would end up otherwise being versioned as if non-breaking.) If it is a good idea, I am not certain I know exactly how it should be done, such as whether the commit modifying gix-features/Cargo.toml should be conventional, and whether it is okay to bump the hard-coded gix-features versions in dependencies that refer to it by path (otherwise the build will fail) while making no other change to those manifests at the same time.

To make these questions more concrete, and also in case the way I have thought of turns out to be workable, I have opened #1957 to bump the gix-features version.