Handling "cyclical" dependencies upon new release?

General Usage
,
1

I have a package (A) that is in its 0.3 versions, and I am about to update it to 0.4. To generate the documentation, I use two other packages (B, C) that depend on A. For the moment, I cannot build the documentation of A because the versions of B and C don’t yet work with the updated version of A v0.4, and I can’t make them work because A v0.4 is not currently released.

Initially, I thought about allowing A v0.4 in B and C, but this will not really solve the problem as they might not be fully compatible, so the first release of the documentation of A is going to have some issues.

My current idea is to release A v0.4.0, update B and C so that they work with it, release updates of these two, and then tag A v0.4.1 with a fixed documentation.

I can definitely live with this solution, but I wanted to check that there was not a more Julianesque way…

2

I would probably have development branches of all three packages ready to go, in sync, before releasing the new version of A.

In the documentation of that release, have the dependencies B and C be particular commits for each. But then fix it as soon as you update B and C.

1 Like