Add release versions appstream files to
Needs ReviewPublic

Authored by jriddell on Jul 16 2019, 12:49 PM.




This adds the KDE Applications version to all projects. That makes sense since it's the version number used in the tars and so the version number user in the packaging.

But if it's not wanted on apps which prefer to use their own internal version number I'm not sure how to distinguish them. Check for cmake having a line like this?


Diff Detail

R497 Release tools
No Linters Available
No Unit Test Coverage
Build Status
Buildable 16148
Build 16166: arc lint + arc unit
jriddell requested review of this revision.Jul 16 2019, 12:49 PM
jriddell created this revision.
aacid added a comment.Jul 16 2019, 1:25 PM

Each time you have proposed this i have pointed a script we have that gets the proper version from the cmake file.

Please go and check my previous comments.

If you can't find it i will point to it one more time.

jriddell updated this revision to Diff 62060.Jul 19 2019, 2:14 PM
jriddell edited the summary of this revision. (Show Details)

Add script to update appstream versions

Given this is going to the release-tools repo and the other code that also does this cmake trace thing to get the version is also in the release-tools repo do you think you could refactor it a bit to they share code?

If python is not your thing maybe @adrianchavesfernandez that did the "original" code can help you there?

jriddell updated this revision to Diff 62855.Jul 31 2019, 2:09 PM
  • move common functions to a common file
adrianchavesfernandez requested changes to this revision.Aug 5 2019, 11:04 AM
adrianchavesfernandez added inline comments.

Why are these values hardcoded here?

This revision now requires changes to proceed.Aug 5 2019, 11:04 AM
jriddell updated this revision to Diff 63193.Aug 6 2019, 2:07 PM
  • use the config file for config settings

Maybe we should modify both README files to simply point to


While at it, this syntax is probably better:


I am guessing this is not what this script does.

You never imported Path in this file. Please, make sure your changes do work, there are no test and I’m likely to miss critical errors.


I’m not familar with the whole codebase, but it seems like we are simply moving the part where this data is hardcoded from a source file to a config file.

I think the simplest approach which does not imply hardcoding would be to accept these values as command-line parameters in the new script.

To make it better, we could:

  • Allow to alternatively specify APPSTREAM_UPDATER in a user-specific configuration file (one that is not Git-tracked).
  • Allow to pass the date in ISO format, and make the conversion to the desired format in the script itself.

Whatever the approach, the README should be updated accordingly.

This revision was not accepted when it landed; it landed in state Needs Review.Thu, Sep 5, 7:04 PM
This revision was automatically updated to reflect the committed changes.
jriddell marked 3 inline comments as done.
jriddell reopened this revision.Thu, Sep 5, 7:17 PM
jriddell marked an inline comment as done.
jriddell updated this revision to Diff 65477.Thu, Sep 5, 7:17 PM
  • add appstream version script
  • move common functions to a common file
  • use the config file for config settings
  • update README, import path
  • fix imports
  • fix release date, update README

I'm not sure of the purpose in adding the option to use command line switches, the scripts already have that config file so seems easiest to reuse it.

There's no document with a good summary of how to do a release and no documentation of add-bugzilla-versions anywhere so I added them into README but it does feel like it could do with more description

aacid added a comment.Thu, Sep 5, 7:27 PM

There's no document with a good summary of how to do a release