added package_version() in Lua, removed version module
It's generally useful to export current package version, so I added that. Fixed some problems in the version module:
- Custom build version results in wrong information
- Empty response raises error (when blocked for example)
- Malformed response raises error
- Double event initialisation
Merge request reports
Activity
added feature label
added 494 commits
- b2c003be...400941fb - 493 commits from branch
master - b077f912 - added package_version() in Lua, catched some errors in version, added test
- b2c003be...400941fb - 493 commits from branch
The linter fails because of some other changes merged to master:
not ok 39 tests/config/keyfile/nonexist_keyfile1.test.lua:2:1: (W122) setting read-only field 'keyfile_default' of global 'trust_anchors' not ok 40 tests/config/keyfile/nonexist_keyfile2.test.lua:2:1: (W122) setting read-only field 'keyfile_default' of global 'trust_anchors' ok 41 tests/config/test_utils.lua not ok 42 tests/config/tests/keyfile/nonexist_keyfile1.test.lua:2:1: (W122) setting read-only field 'keyfile_default' of global 'trust_anchors' not ok 43 tests/config/tests/keyfile/nonexist_keyfile2.test.lua:2:1: (W122) setting read-only field 'keyfile_default' of global 'trust_anchors'@tkrizek Please have a look at this and make sure the versioning scheme here makes sense to you and can express versioning in all the distros we build packages for. Thanks!
assigned to @tkrizek
The version number shouldn't be considered as three integers. That only applies to regular releases. We're also using development versions, which currently have the format of
2.1.1.40.gd71db413.This format will have to change once we start using a different branching model to also support older branches. Then I expect we'll be using same version as in
knot-version.m4, which can also produce versions like2.7.devor2.6.5.dev.sortcan properly handle all of these versions. The complete list of possible versions looks like this (sorted, ascending):2.1.1 2.1.1.40.gd127b73e 2.1.1.dev.1521451111.g83923cba (future) 2.1.2 2.1.2.dev.1521451112.g4c168228 (future) 2.1.dev.1521451113.g2d2e34e8 (future) 2.2.0When the version is checked, I think the entire version string should be taken and compared lexicographically to the latest version from DNS TXT. Then, the user should be notified only when the current version is older (not different) than the latest.
Did you figure out whether you want return it as a string, or as a tuple in the end? I'm happy to keep it as it is or revert the change to tuple @pspacek asked for. The only thing that's useful to me is that I can return a running version in CH TXT responses.
I'm sorry for the delay, this totally fall through cracks. @tkrizek will decide what to do with it today.
-
@vavrusam We can use the string representation as proposed in https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/412#note_72742 . These string versions can compared using lua string comparison, so it's possible to do version checks such as
version >= '2.3'. I've tested all the above cases and it handles them as expected.Sorry for the delay!
For the comparisons we would need to make sure that we don't release e.g.
2.10, but that seems a reasonable rule anyway, at least for some medium-term future (until9.9).Edited by Vladimír Čunátadded 210 commits
- 733ebbe3...d316da92 - 209 commits from branch
master - 0329d1bc - added package_version() in Lua, catched some errors in version, added test
- 733ebbe3...d316da92 - 209 commits from branch
@tkrizek rebased and updated to text format
@tkrizek Ready for merge?
-
@vavrusam We were considering the use cases of this module with @pspacek and we couldn't come up with any reasonable ones. Are you only interested exposing the
package_version()function to lua, or do you intend to use theversion.luamodule as well?If it's only about
package_version(), we're considering to drop the version module entirely. Distribution packages don't use it by default and those who decide to compile kresd by themselves have more appropriate means to find out about new versions than from the log (e.g. knot-resolver-announce mailing list; twitter or watching the git repo for new tag)The CVE detection/warning also wouldn't work as is. The
CVEpublished in theet.knot-resolver.cz TXTrecord is the latest found CVE and it stays there until a new one appears. Thus, users would get false positive warnings with the current implementation, when updating from a version that already has the latest CVE fixed.If you're not interested in the
version.luamodule and just want the API, feel free to remove it in this MR.Thanks!
I have no use case for the module, just the
package_version(). I'll remove it then.Edited by Marek Vavrusaassigned to @vavrusam
added 171 commits
-
b2c99a77...4141975d - 169 commits from branch
master - 351a305b - luacheck: added missing module (trust_anchors)
- febcfd7c - added package_version() in Lua, catched some errors in version, added test
-
b2c99a77...4141975d - 169 commits from branch
added 1 commit
- e0c0b112 - added package_version() in Lua, removed version module, added test
added 174 commits
-
ea9bfca9...a861c4de - 171 commits from branch
master - a913cd7f - luacheck: added missing module (trust_anchors)
- b4d9c9ee - added package_version() in Lua, removed version module
- 0e3de4fc - distro/deb: remove version.lua module
Toggle commit list-
ea9bfca9...a861c4de - 171 commits from branch
added 5 commits
-
0e3de4fc...df546afb - 2 commits from branch
master - 97a43e26 - luacheck: added missing module (trust_anchors)
- fcdf8d6e - added package_version() in Lua, removed version module
- b138e3a8 - distro/deb: remove version.lua module
Toggle commit list-
0e3de4fc...df546afb - 2 commits from branch
enabled an automatic merge when the pipeline for b138e3a8 succeeds
mentioned in commit ce809057
