-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version incomplete in SPEC file #18
Comments
I made it 1.0 because it wasn't being kept in sync with the reality. Did you like 1.0.0 better? 1.0 at least isn't wrong, it's just partial. And it's actually ignored by obs builds (replaced with something derived from the latest tag), that's why (almost) nobody cares. |
Yes, I noticed. But for most of the packages on SFOS we have correct version information set as a part of the releasing process. OBS does ignore it, indeed. However, community OBS is not up yet for working on ports with it. So, while building with tbuilder, I will get 1.0 as a version (+ release component). I personally think that we should not assume building on OBS or building with git tags. If the SPEC is provided, I expect it to be in sync as a part of the release process. Note that we have few issues like this for several SFOS packages leading to the discussion on whether git tags are good enough. See example at mer-hybris/qt5-qpa-hwcomposer-plugin#89 |
Just an additional note: I don't expect it to be fixed for the current version. But maybe it would be possible to incorporate the version tracking in future as a part of the release process. |
Well, I'm keeping .spec version in sync with the latest tag for the packages that I maintain, so I'm definitely for it )) I wasn't considering myself a maintainer of this package, though. |
Please set the full version in SPEC file as a part of the release. Right now we have 1.0 for 1.0.12
The text was updated successfully, but these errors were encountered: