meta-version: confirm collection version is >= 1.0.0

[thedoubl3j]

confirm via galaxy.yml file if key version: is greater than or equal to 1.0.0.

rule should be optional and only enabled at users discretion. Error level should be error/fatal (1) as Automation Hub cannot house content that is not fully released via semantic versioning standards.

based off of code found here

[KB-perByte]

This looks interesting, I would take a look at this enhancement.

CC, @ssbarnea

[felixfontein]

Seriously, but this rule makes zero sense and should be removed. There is no single reason I can think of why a collection version should be 1.0.0 or larger.

[felixfontein]

(If the intention was that this is optional and needs to be explicitly enabled, then the current implementation does not take this into account.)

[ssbarnea]

@felixfontein That rule was included in shared profile, so that is why is enabled by default (no profile mentioned equals with everything being enabled). As @thedoubl3j showed, there is code inside galaxy importer that requests a version like this. I guess the reason is related to semver, as nothing before 1.0.0 can be trusted for keeping backwards compatibility. The rule can be disabled, so I do not find this as too bad.

@cidrblock WDYT?

Update: At the some time, I find bit bit awkward that our own cisco.nxos collection fails this test because it uses 0.0.0 inside the code base, even if there is a comment that mentions that effective version is computed at build time.

[felixfontein]

@ssbarnea collection releases with version < 1.0.0 have always been possible on Ansible Galaxy and still are. See for example https://galaxy.ansible.com/community/internal_test_tools and https://galaxy.ansible.com/felixfontein/acme, which both still have 0.x.y versions, and most community and cloud collections, which started with 0.1.x (https://galaxy.ansible.com/community/general, https://galaxy.ansible.com/amazon/aws) or even 0.0.1 (can't find an example now, but I'm pretty sure I've seen that in the past).