Conan2 is great, but not just

As a long-time user of Conan version 1, I’ve found it to be a reliable and effective solution for managing C++ dependencies, despite a few minor issues. Over the years, I’ve advocated for Conan, recommending it to colleagues, implementing it in various projects, and even authoring a blog post about its benefits. The highly anticipated Conan 2 was released recently, promising significant improvements and a wealth of new features. But rather than being a direct successor to Conan 1, Conan 2 is essentially a different software, a second system that introduces many new challenges and considerations for me, and maybe even for the C++ development community.


If you are new to Conan, use it. Conan 2 is a good tool and will become better over time. This post is for users who have to manage the migration to the new version. And not even all users are affected. However, it is vital to provide feedback that highlights problems and challenges. It may help prevent such a break in the future for Conan and other projects.

Challenges Introduced by Conan 2

Conan 2 has introduced a number of challenges for its users who are coming from Conan v1 that deserve attention. This is a brief overview of some of the main concerns that I have surfaced with the launch of this new version.

Compatibility Issues

Recipes changed, the command line interface changed, and the build system and project integrations changed depending on your usage of Conan 1. Everything changed.

With all those breaking changes, users face difficulties adapting existing projects to the new version. This lead to additional work, cost, and potential loss of productivity.

Learning Curve

When a program undergoes drastic changes, users must invest time and effort in learning the new features and understanding the modified workflows. This learning curve can be frustrating for users, as it can slow down their progress and limit their efficiency in the short term.

This, again, adds cost and a potential loss of productivity.

Fragmentation and Maintenance Challenges

Moving already working projects to Conan 2 is a considerable challenge. And it is not just about the work but also about the time and the risk of introducing new bugs.

Some users or projects may embrace the new version, while others prefer to stick with the older, more familiar version. This can result in fragmentation and can hinder collaboration between projects and teams.

And you might have to support both versions for quite some time. This, again, adds cost and a potential loss of productivity.

Less, or Different, Functionality

If you have implemented your Conan project in specific ways fully supported in Conan 1, you may find that Conan 2 no longer supports these ways. This may lead to a situation where you have to change your project to fit the new version.

And this might affect not just build engineers but also users confronted with different tool usage and integration. This brings you directly back to the topic above, Fragmentation and maintenance challenges.


The introduced challenges have some consequences. For me, the two most significant are the risk of cost explosion and the erosion of trust.

Risk of Cost Explosion

The transition to Conan 2 necessitates a rewrite of recipes and significantly adjusting workflows for its users. This process can lead to a cost explosion, as developers must allocate considerable time, effort, and resources to adapt their projects to the new version.

In many cases, this expenditure may not be justifiable, particularly for companies and projects with limited budgets or tight schedules. This cost explosion can further exacerbate the negative impact of drastic changes, as users may be deterred from adopting the new version or even continue using Conan altogether.

Consequently, the developers of Conan should be conscious of the financial and resource implications that such a substantial shift did impose on parts of their user base and strive to minimize the associated burden.

Erosion of Trust

When users grow accustomed to a program, they develop trust in its stability and reliability. Drastic changes can erode this trust, as users may feel unsure about the program’s future direction and whether it will continue to meet their needs.

The current situation raises the question, when will the next expensive breaking change happen? Shall users stick with Conan or invest the time they have to invest in a search for alternatives?

Another Issues

Finally, I want to add two topics I find important to highlight, and I wish to be addressed by my C++ package manager of choice.

Embrace The Importance of Stability and Compatibility in the C++ Ecosystem

Some communities might be used to breaking changes. But this is not the case for the C++ community.

In the realm of C++ development, stability and compatibility are highly valued attributes. C++ has a long-standing reputation for performance, reliability, and portability, which are key factors in its widespread adoption across various industries, including finance, gaming, and high-performance computing. By introducing drastic changes to Conan, a crucial tool in the C++ ecosystem, the developers risk undermining these cherished qualities. Ensuring that C++ projects remain stable, interoperable, and compatible is vital to preserving the trust and confidence of the C++ community, as well as maintaining the language’s strong position in the software development landscape. Therefore, it is crucial for Conan’s developers to be mindful of the importance of stability and compatibility while advancing their package manager’s functionality.

Openness of the Server/Remote Component

Another concern with Conan is the server component’s limited openness. While the client-side part of Conan is open source, the server-side documentation is either inadequate or entirely absent. The lack of proper documentation restricts users from easily implementing their own server solutions, thereby diminishing the advantages of an open-source ecosystem.

As a result, most users rely on JFrog Artifactory, which offers a Conan-compatible server implementation. Although the C++ part of JFrog Artifactory can be used for free, its approach to open source has raised concerns about potential abuse of the open-source spirit. JFrog’s business model blurs the line between proprietary and open-source software, leading some users to question the transparency and long-term intentions of the company.

This situation not only undermines the trust in Conan as a whole but also raises questions about the broader implications for the C++ community. It is essential for the Conan developers to address these concerns and work toward fostering a more open and transparent server-side ecosystem, thus upholding the values and expectations of the open-source community.


I have working projects using Conan v1 for dependency management on Windows, Linux, MacOS, as well as for cross-compilation to embedded targets like Linux, iOS, and Android. Conan 2 forces me to rewrite recipes and adjust my workflows. This is a considerable effort. I am frustrated about that and I am probably not alone with this situation. Conan 2 does not add a lot I missed, but removed a lot I needed.

For me, Conan 1 had resolved the cpp package manager issue, and there was an expectation that Conan 2 would further improve this solution. However, after this break, this has not been the case. Instead, Conan 2 has emerged as a separate system altogether. Now, I might have to revisit my point of view for a comprehensive and trustworthy package management solution. Only time can tell.

I hope that in some future, I will look back at the current situation and see it as a temporary setback. And that Conan 2 is a valuable solution, not a second system of once-promising software.