#12 · closed · 19 comments
~~~ $ cmake -D_CMAKE_TOOLCHAIN_PREFIX=x86_64-w64-mingw32- [...] Could not find a package configuration file provided by "c++utilities" (requested version 5.0.0) with any of the following names: c++utilitiesConfig.cmake c++utilities-config.cmake ~~~ So as can be seen tagparser is requesting c++utilities version 5.0.0. But that doesnt exist: https://github.com/Martchus/cpp-utilities/releases
The latest release of tagparser requires c++utilities 4.17.0: https://github.com/Martchus/tagparser/blob/v8.3.0/CMakeLists.txt#L181 That the unreleased Git master of tagparser requires the unreleased Git master of c++utilities is not a mistake.
:|
Just build the latest release of everything or the latest Git master. What's the problem?
Asking for a version thats not publicly available is... not good i dont know the innerworkings of Cmake but I would hope a better solution would be available than that should be requesting version `master` or something like that looking closer, i see that it is actually available: https://github.com/Martchus/cpp-utilities/commit/d99a611fbcb62dfad82749fc89d5b21bba582f04 ...for 2 years now. Why havent you pushed a tag or release in 2 years? Most repos (including my own) push a tag immediately after the version commit.
Version 5 is still under development. Development of v5 has started on its own branch with the commit https://github.com/Martchus/cpp-utilities/commit/d99a611fbcb62dfad82749fc89d5b21bba582f04. At this time the main development still focused on v4 and v4 releases have been tagged. Currently I'm already focusing on v5 and the next release will be v5.0.0 (unless I need to do a patch release for the v4 branch before). v5 will be release when it is ready. Since the current state (WIP v5) is incompatible with v4 regarding API and ABI I have already incremented the version. This way CMake will prevent you from using incompatible versions together and you get the error message you've got instead. Note that the latest *Git master* of c++utilities, tagparser and tageditor are compatible with each other and CMake will not refuse to build them. The same counts for the latest *released version* of those projects. I really don't see a problem here. I'm wondering why you're trying to mix releases with development versions in your builds.
the version commit should be the last thing you do after all changed are made, then you make the version commit as by your own admission - the repo in its current state is not version 5 if you wish to commit a unfinished version 5 it should be done on a topic branch i was looking forward to working with you again but your development choices are making that difficult
> after all changed are made, then you make the version commit That might be more intuitive. But also other projects do it that way. E.g. if you build the latest VLC "nightly" and open the about dialog it tells you version 4.something although the latest release is 3.0.6. The idea behind my approach is that an ABI or API change compared to the last release is instantly announced. > as by your own admission - the repo in its current state is not version 5 I agree - it is version 5 WIP. Of course that version does not formally exist and is under continuous change until the real version 5 is released. > if you wish to commit a unfinished version 5 it should be done on a topic branch That's actually how I started. I even added c++utilities-v5 branches to my other repos like the tagparser for the adaptions. But at some point *all* development only happened on those branches anymore so I decided to merge those on master simply because master is where the main development is supposed to happen (and not where you find the latest stable release). I just had a [brief look](https://git.videolan.org/?p=vlc.git;a=blob_plain;f=configure.ac;hb=master) and it seems VLC devs also work with an unreleased version number on their master. So I'd claim that doing so is at least not completely uncommon. > but your development choices are making that difficult Maybe finding out how I do things was difficult but if you would like to contribute then it is actually quite easy: Just checkout the latest master of *every* repository and base your work on that. At any time master is the right branch to base your work on because that's the branch development focuses on. (And if you don't want to contribute and just use the latest stable version it is also simple: Just download the latest release of everything.)
these repos all push release at time of version commit... stars | link -------|---------------------------------- 75,743 | https://github.com/torvalds/linux 38,578 | https://github.com/bitcoin/bitcoin 35,272 | https://github.com/opencv/opencv 34,714 | https://github.com/protocolbuffers/protobuf 27,684 | https://github.com/git/git
OpenCV actually does it quite similar to me: https://github.com/opencv/opencv/commit/371bba8f54560b374fbcd47e7e02f015ac4969ad The difference is that they also have a "pre" flag which they remove right before the release. Adding such a flag in my project files would make sense, too. The current BitCoin release is 0.18.0 and their [master is already on 0.18.99](https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L5). But this shouldn't be a battle who's right or wrong. I've just came up with VLC so that it doesn't look like I'm the only strange person who updates their project version in that way. I've already explained my workflow now and I think it shouldn't be too hard to adapt to it even if it wouldn't be your own choice.
ok, I stand corrected but, the problem is not that some version exists outside of a release the problem is that some project (tagparser) is **requiring** this unreleased version. https://github.com/Martchus/tagparser/blob/8c88298fe8a2611b46b5f9f9716e420bb4fde41e/CMakeLists.txt#L182 so you either need to make c++utilities version 5.0.0 exist properly, or stop have other projects require it. If you can point to a single other project that uses this Byzantine development style, I will be surprised.
Last time I wanted to build some KDE libraries I've noticed that I was also forced to build some further dependencies because on my system I "only" had the latest release installed. I just had a quick look on an arbitrary KDE module and it seems that right now the unreleased KIO depends on the unreleased KArchive: * https://cgit.kde.org/kio.git/commit/CMakeLists.txt?id=e6286a77415bbcbeb6f746c16f9016cf9d4a0e8a * https://cgit.kde.org/karchive.git/commit/CMakeLists.txt?id=03681bb58fbf007cfac8bcef8e4afe37c446195a But still this is not a battle. The KDE example would also be an explanation for me how one can end up trying to build the Git master of tagparser against latest release of c++utilities - I ran into the same problem with other libraries, too.
I see, you are right again. But I wont work with any project that uses such a flawed development system, regardless how many examples there are. If you have a published version of a project, and other projects are requiring that version, then the dependency MUST be tagged, end of story as far as Im concerned. Obviously you disagree so looks like its time to part ways. If you ever change this style let me know, as I had some further work I wanted to do with TagEditor. Thanks.
I think that is a common problem when closely related libraries are split into multiple repositories. If the issue was called "GCC version 10" I would definitely get your point. I'm wondering why this is so important to you but that's your decision of course. And it seems like I don't have a Déjà vu :-) https://github.com/Martchus/tageditor/issues/26
@Martchus I dont expect to change your mind, and I havent changed mine. But I would add the proper way to "instantly announce" an ABI or API change is to use semantic versioning. Again many popular projects already do this: - https://github.com/django/django/releases/tag/3.0rc1 - https://github.com/git/git/releases/tag/v2.24.0-rc1 - https://github.com/golang/go/releases/tag/go1.13rc1 - https://github.com/tensorflow/tensorflow/releases/tag/v2.1.0-rc1 - https://github.com/torvalds/linux/releases/tag/v5.5-rc1 and its been documented here for several years: https://semver.org
This library *is* using semantic versioning. So the version is specified and incremented according to "Summary" on https://semver.org. Note that it says "A pre-release version **MAY** be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.". Beside that optional statement the specification does not deal with development versions (any version tracked by the VCS without release tag). It also does not specify at which point *during development* the version bump must happen. Hence I don't see how it is related here. This issue is about the "problem" that a *development version* of a project depends on the *development version* of another project (rather than the latest release version of that project).
@Martchus I am honestly taken aback as to why this extremely common workflow seems alien to you. Imagine project `sunday` current version is `1.0.0`. The flow for introducing version 2 would be: 1. commit something that is considered to be part of version 2 2. commit a version change `2.0.0-rc1` 3. commit something else that is considered to be part of version 2 4. commit a version change `2.0.0-rc2` 5. make final change to produce Minimum viable product version 2 6. commit a version change `2.0.0` Can you explain why hundreds of production projects use this flow every day, but that you are so against it? and if so, why? Its obvious that your flow introduces confusion, so whats the benefit? What serious benefit comes from the flow youve chosen? Surely some strong benefit is available for you to break from this established norm?
Is it really common to tag a pre-release *each time* a change targeting the final release is made? I suppose pre-releases are versions to encourage people testing certain (but not an arbitrary) development version. > Its obvious that your flow introduces confusion I haven't got any feedback in that regard except from you. By simply following the instructions one will not run into this issue. > but that you are so against it? Note that I am not generally against tagging release candidates. I just haven't taken the effort yet to tag any on my projects and considering the small user-base it is also likely not worth the effort.
@Martchus > I haven't got any feedback in that regard except from you. surely you must know this is a logical fallacy: https://en.wikipedia.org/wiki/Argument_from_ignorance the amount of people that have complained does not determine the validity of a complaint. A complaint can and should be judged on its merits. Do you have any constructive feedback?
I'm just saying that other packagers/users did not run into that problem (they sometimes run into different problems) and that it can be easily avoided by following the instructions. Note that my time is limited so I can not put effort into any conceivable improvement. Hence it seems logical focus on issues which affect more people. Deducing that by the amount of feedback is indeed not optimal but I have no other data.