https://github.com/geany/geany/blob/4a1fda547fecdd3b5cb49d8f345cef84741210c3... At the same time git tag is `2.0.0`. It would be good to keep version and git tag in sync.
This sounds like a continuation of https://github.com/geany/geany/commit/13bc05d80f456d8ed745e4fbfbf4286a49d1ac..., but I still don't understand what's the actual problem. Yes, it's not the same version string, but what harm does it do?
For me, the rationale here is: * tags are (only) a developer thing, and we make them very consistent: `major.minor.micro` * the version in *configure.ac* (or *meson.build*) ends up being visible to users (about dialog, tarballs, etc.), and adding an extra `.0` doesn't add any value -- and rather look odd.
If this causes a hard to solve problem, we can see what to do (even if it's adding redundant tags), but for now "it would be good" doesn't convince me.
Sorry forgot that I've already mention about that.
As I wrote I'm using autogenerated from git tag tar balls as input resources to package geany. Usually geany-plugins requires the same version of the geany on build stage. Reason of using that is that with such In geany-plugins.spec I have line: ```spec BuildRequires: pkgconfig(geany) >= %{version} ``` to force use exactly the same version of the geany. Issue is that in generated geany.pc file is "Version: 2.0" so it causes that geany-plugin build fails because it cannot find `2.0.0` version.
Simple it is a bit unusual skipping that last digit if it is "0". I have at the moment +5k source packages and literally none of those packages source code maintainers uses that kind of versioning convention. IMO simpler would be just keep version and tag the same .. 🤔
Well [semver](https://semver.org/) requires a three part version, always, and I doubt users of Geany (an IDE after all) will be worried about `X.0.0`.
I don't want to ague but I don't see anything about skipping last 0 in version string. Other thing is that this semantics is extremely not compliant with most of the package managers because `-` is no allowed to be used by most of that kind of software (rpm, dpkg, Solaris IPS, *BSD package manager and even old SySV PM). Other fact is that this semantics documentation was released more than TEN YEARS AGO https://github.com/semver/semver/tags and in issue tracker you can find tickets about use for example dash in version string.
So .. please don't look on outdated documentation.
I've only presented in what kind situations your convention causes some issues on interaction between geany and geany-plugins causes issue on packaging both projects. In other words this documentation changes nothing in context of exactly that case. You can ignore that case but it will change nothing.
Just please look around and try to find another project which uses the same convention.
Nevertheless this issue ticket is not about use tree parts in version string but about skipping 3rd part of the version in sone exact cases with use three parts version in case of git tag. It causes some versioning duality. Only this and nothing more.
I don't want to ague but I don't see anything about skipping last 0 in version string.
Correct, as I said "semver requires a three part version", that means its not allowed to shorten the version, which is in furious agreement with you, and I said I don't think any users will be worried about a three part version, so why are you arguing?
I am not sure what you are on about the dash, Geany doesn't use dashes on any release version.
I don't want to ague but I don't see anything about skipping last 0 in version string.
Correct, as I said "semver requires a three part version", that means its not allowed to shorten the version, which is in furious agreement with you, and I said I don't think any users will be worried about a three part version, so why are you arguing?
Again: this issue is not about use two vs. three pats version string, and which one is allowed and which is not It is about use three AND two parts version string AT THE SAME TIME in case tagging and actual versioning.
OK, got it. Well, it's kind of a special case as IIUC you're using Geany-Plugins' version to depend on Geany; but I get it.
Well in the end if it simplifies things I'm fine using `major.minor.micro` everywhere (only `2.0.0` will look kinda ugly (objectively :wink:), `2.1.0` will be fine), I don't really care; I just didn't see a reason to change what we'd been doing since forever. Or we could switch to `major.patch`, as Geany has a history of randomly updating `major` anyway :smile:
👍 Thank you very much 😄
Use everywhere exactly the same version string is simpler .. just and only 😃 And that simplicity is not causing reported issue 😋 Number of components is not relevant in case of both geany and geany-plugins as log as withing project is used the same version string everywhere 😅
Feel free to close this ticket at any time. One more time .. thank you.
github-comments@lists.geany.org