# Handling "cyclical" dependencies upon new release?

**URL:** <https://discourse.julialang.org/t/handling-cyclical-dependencies-upon-new-release/50910>\
**Category:** General Usage\
**Tags:** package, documenter\
**Created:** [November 28, 2020, 7:07pm UTC](https://discourse.julialang.org/t/handling-cyclical-dependencies-upon-new-release/50910 "2020-11-28T19:07:52Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![tpoisot](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tpoisot/32/19812_2.png) [@tpoisot](https://discourse.julialang.org/u/tpoisot)\
**Post date:** [November 28, 2020, 7:07pm UTC](https://discourse.julialang.org/t/handling-cyclical-dependencies-upon-new-release/50910/1 "2020-11-28T19:07:52Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![pdeffebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pdeffebach/32/10320_2.png) [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)\
**Post date:** [November 29, 2020, 2:40am UTC](https://discourse.julialang.org/t/handling-cyclical-dependencies-upon-new-release/50910/2 "2020-11-29T02:40:13Z")

</div>

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`.