Make command-line tools accept minor I/O version numbers as well.
Opened this issue · 6 comments
We've added support for requesting a specific major I/O schema version to various tools, such as kcidb-schema, kcidb-validate and so on, a while ago. That was done when we had separate objects for major versions only. Now we have separate objects for minor versions as well. Make the tool accept a version string as well (as handled by kcidb.misc.version() argument type, e.g. v4.1), and outputting the corresponding version of the I/O schema. However, make it still accept just the sole major version number and output the latest minor version with the specified major number (as it was done before). This would involve modifying the kcidb.misc.argparse_schema_add_args() function.
Hi currently I am working on this!
Will generate PR soon!
@octonawish-akcodes, not exactly. The #394 needs to make the database tools accept a full I/O version where we specify the database schema (picking a corresponding one). This issue is about the tools which purely operate on I/O schema versions (not DB schema versions), like kcidb-schema and kcidb-upgrade. Although #394 could possibly reuse the code for parsing (and validating) I/O schema versions required for this one.
Removing @Biswajit-Behera from the assignees, as Outreachy's initial contribution period is now over.
@spbnick what does it mean major and minor number of schema? Why are these numbers important?
the input string is v4.1, it means major is 4 and minor 1?
4.1 is not valid because it requires v prefix?, 4 is not valid too because minor is 0?
what does it mean major and minor number of schema? Why are these numbers important?
The schema documents the function of the major and minor version numbers. But in short, minor number increases signify backwards-compatible changes, and major number increases - backwards-incompatible. Check out the I/O schema versions in kcidb-io for more context.
the input string is v4.1, it means major is 4 and minor 1?
Yep! Except we shouldn't require the v (I suspect I just didn't think the example in the description through).
4.1 is not valid because it requires v prefix?, 4 is not valid too because minor is 0?
Currently we accept just a single integer signifying a version with the specified major number and the latest minor number. We also need to accept a complete specification of the version (both major and minor numbers). I don't think we need to require the v prefix. Just e.g. 4 (meaning v4.<latest_minor>) or 4.1 (meaning v4.1). Even though looking at it as a rational number, we might read 4 as 4.0, we need to support the old method, at least for now, and anyway version arithmetic is a little weird, so hopefully we'll be able to remove support for single-number interface before anybody complains 🙈