Hey @uilianries -- will removing this legacy recipe become a breaking change for anyone still using conan 1.x? Are there any potential workflows that might get disrupted if we remove this code? Does the current code even still work for those on 1.x?

@jtdavis777 Hello!

will removing this legacy recipe become a breaking change for anyone still using conan 1.x?

Yes and no. The recipe kept here will no longer be available, but for those users still using Conan 1.x, they will be able to use the frozen recipe and package from Conan Center:

• Froken recipe with Conan 1.x support: https://github.com/conan-io/conan-center-index/blob/conan1-frozen/recipes/flatbuffers/all/conanfile.py
• Packages still available on Conan Center:

$ conan --version
Conan version 1.66.0
$ conan search -r conancenter flatbuffers
Existing package recipes:

flatbuffers/1.11.0
flatbuffers/1.12.0
flatbuffers/2.0.0
flatbuffers/2.0.5
flatbuffers/2.0.6
flatbuffers/2.0.8
flatbuffers/22.9.24
flatbuffers/22.9.29
flatbuffers/22.10.26
flatbuffers/22.11.23
flatbuffers/22.12.06
flatbuffers/23.1.4
flatbuffers/23.1.21
flatbuffers/23.3.3
flatbuffers/23.5.26
flatbuffers/24.3.7
flatbuffers/24.3.25

Are there any potential workflows that might get disrupted if we remove this code?

No, the folder .github does not contain traces of Conan usage there. For those users who are consuming Conan in their CI, there is an extensive DevOps Guide showing how to avoid external breakage, but using lockfiles and other features to keep reproducibility.

Does the current code even still work for those on 1.x?

It builds with Conan 1.x, but has deprecated features and packages most of .pc and .cmake files, which may break users when consuming the very same produced by Conan generator. For instance, Conan is capable to generate both FindFlabuffers.cmake and flatbuffersConfig.cmake, using the information from the recipe and following the Conan profile used, it guarantees that what the consumer asked, will fit exactly with the information in those .cmake produced files (e.g Release/Debug, shared/static...)

Conan 1.x has now been deprecated for more than 2 years by Conan 2.x. Only security patches are absorbed, but no new features or backports are included. Still, Conan has been helping as much as possible to move users toward 2.x.

When I opened that PR to include this Conan recipe, the Conan project had no resource to keep a central repository with official recipes. Later, the Conan-Center-Index was created, and pre-built packages were stored in an Artifactory instance, making those packages publicly available. As a result, we no longer needed to push recipes directly to upstream projects and consume their CI to build/publish a package. Still, receiving reviews from the upstream on ConanCenterIndex is always welcome.

Please let me know if I have clarified your points sufficiently. Regards!