Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
The blogpost about minimal version selection mentions support for cyclic dependencies between modules.
Also, the blogpost shows the dependencies between the same versions, i.e.
The more likely real-life scenario would probably look closer to something like this:
I am still not sure if such tightly coupled separate modules is a good idea (why not just merge them into one module?), but at least it would mean no 'chicken and egg' problem for releasing process anymore.
FWIW we have real repositories that have cycles between them. The cycles usually involve tests. An example is when a server implementation lives in one repo and its client in another. To test the client, its tests import the server so that they can verify properly that the client code runs against a real server. The API parameters live in a package in the client so that the client package can be imported without importing the heavyweight server package.
Releasing is indeed fairly painful, and I think if I was doing this again, I'd avoid the cyclic repo dependency. Given that we use a git-commit-locked dependencies, the recipe for making a change looks something like:
At this point both client and server lock files point to valid commits on each other and we can proceed as normal.
I think one could probably use a similar approach with vgo.
Thinking about it, I think the main reason this was a problem was that we were making incompatible changes. With major versions as separate import paths, things might be easier.
Knowing what I do now, I think a better approach would be to avoid importing the server code in the client at all and make the tests build the server as an entirely separate binary. That way you can easily test the client code against different server versions too.
@rogpeppe thanks for the real world example. Since
What I don't like about this recipe (apart from being very complicated) is that the version you tested is not the same you released, and potentially there could be more (untested) changes in between them.