v0.3.9 semver failing on rpm version format 9.99 but pass for format 9.99.9

[milind69]

Describe the bug new semver version match if match is format 9.99 it fails but if format is 9.99.9 passes

How To Reproduce

package:

: installed: true versions: and: - have-len: 1 - contain-element: semver-constraint: ">=1.10" kernel: installed: true versions: and: - have-len: 1 - contain-element: semver-constraint: ">=3.10.0" mypkg info -bash-4.2$ rpm -qa --info Name : Version : 1.11 Release : 1.lrh7 **Expected Behavior** expect package to pass **Actual Behavior** -bash-4.2$ /usr/local/bin/goss -g package-version.yaml validate -f tap 1..4 ok 1 - Package: : installed: matches expectation: [true] not ok 2 - : version: Error: Expected a valid semver constraint. Got: : >=1.10 ok 3 - Package: kernel: installed: matches expectation: [true] ok 4 - Package: kernel: version: matches expectation: [] **Environment:** - v.0.3.9 - RHEL7

[milind69]

correcting the yml file as it dropped pkg name

package: my-package: installed: true versions: and:

• have-len: 1

• contain-element: semver-constraint: ">=1.10"

  kernel: installed: true versions: and:

  • have-len: 1
  • contain-element: semver-constraint: ">=3.10.0"

my-package info -bash-4.2$ rpm -qa my-package --info Name : my-package Version : 1.11 Release : 1.lrh7

where my-package is proprietary package can not share more info

[milind69]

also looks like -f json is providing oneliner output like -f json_oneline

[aelsabbahy]

As per the semver spec:

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

https://semver.org/#spec-item-2

I think the feature you want is requested in this PR which is still open: #435

See my comment here where I explain why using semver for rpm matching can give incorrect results: https://github.com/aelsabbahy/goss/issues/435#issuecomment-561704683

Please let me know if the goss manual needs to be re-worded to clarify this further.

RPM version matching/ranges is something I would like to support in the future, but it does not currently exist in goss.

If this feature is important to you add a :+1: to the first comment in #435

Thanks for using goss and providing feedback!

[aelsabbahy]

Regarding JSON, json_oneliner will be deprecated. See the second bullet on the release notes:

json output now supports -o pretty and behaves like json_oneline. json_oneline will be deprecated in the future

https://github.com/aelsabbahy/goss/releases/tag/v0.3.9

[milind69]

Thank you for reply , I am new to goss still learning but honesty I am lost when to use semver matcher as the example in the manual is not very clear.. this is good tool but manual lacks example in some advanced area like matching without template and now semver .. can you give real life example for this

[milind69]

can you give some real life example than this ? example: content:

• 1.0.1
• 1.9.9 matches: semver-constraint: ">1.0.0 <2.0.0 !=1.5.0"

not sure what "example:" means in the example.

[aelsabbahy]

If you have a package that adheres to strict semver format semver-constraint can be used for that. That's about it for now. You'll have to be careful of the gotchas that I linked earlier where rpm and semver differ.

I comment on how semver-constraint is not immediately useful and where it may pair up with future work on the PR, see this comment for more info: https://github.com/aelsabbahy/goss/pull/508#issuecomment-562362162

[aelsabbahy]

Closing, since semver-matcher is working as intended and 9.99 isn't semver.