Make a release

[zamazan4ik]

Hi!
Thank you for the such cool library! I'm interested in packaging the library into some dependecy managers. It will be much easier if you make a release on GitHub, so in a package recipe I will rely on some "stable" version instead of specific commit. E.g. it much easier to create a package for Conan with release.

Thank you!

[thed636]

Hi, Alexander!

Nice to see your request!

I think we should wait for #256 and more critical #259. I hope to see both in master until next week. After that, we will be ready to make a 0.1.0 release. Is it ok for you?

@JonasProgrammer Jonas, would you like to continue with your PR for Conan.io package (sorry for the very long delay with this)?

[zamazan4ik]

Yeah, that's will be fine for me. Thank you a lot!

[JonasProgrammer]

@thed636 No problem regarding the delay.

As for the PR, I'd be happy to do that, however right now I'd suggest to wait a bit.

The conan guys have recently completely revamped their global package repository, but they opted to delete any config*.cmake files up there. The result is, that plenty of packages have an incompatible 'CMake interface' as of now, e.g. boost find_package(Boost) gives exactly one target Boost::Boost (note the uppercase B) and there are no separate targets per library; the linked libraries depend on conan options instead (by default, all of boost is included).
For the same underlying reasons, the conanized cmake target of ozo would be ozo::ozo instead of yandex::ozo.

Given ozo's minimum dependencies, one could use the legacy packages and conan generators, but this is not really a good option IMO, as it renders the package more or less incompatible with the central repo (which is required if the end-user wants boost >1.71, for example) and would absolutely prevent ozo's inclusion there down the road.

Luckily, there are a number of people, who are dissatisfied with the current situation and while the no-config*.cmake-policy is unlikely to go away, people are working on getting multiple properly named targets/components per package running. While this is still not as convenient as just allowing proper cmake configs -- basically all the target_compile_options_* and target_link_libraries_* stuff has to be repeated in the conan recipe -- it at least removes the blocker that is the incompatible target names.

TL;DR: Having an ozo package that works as standalone cmake, legacy conan dependencies and new-center-conan dependencies is currently impossible without ugly workarounds, but the underlying issues may be fixed in the upcoming releases.

[thed636]

Hooray! :) The very first release is v0.1.0.
@JonasProgrammer Ok, please let me know when you are ready to made it. And thanks for the explanation!