Management of version tag

[Bialogs]

There are currently no GitHub releases or tags pushed to this repository so I'm wondering what the policy for the inspec.yml version tag is.

Can anyone shed some light? If there is nothing thought out perhaps we can discuss options here.

[aaronlippold]

I would say we have to decide a pattern.

It would seem that we should be tagging our main 'release' on the STIG document itself.

V1R4 , V2R1 etc. which could translate to something like: 1.4 and 2.1 etc.

We could then use the x.y.[###] much like RPM does for updates and fixes ...

So in this last round of revisions we would be at something like:

1.4.5 or something...

[Bialogs]

It would be of benefit to me to use the versioning scheme Aaron described.

[trevor-vaughan]

Wanted to open this back up and try and get it resolved.

I propose the following:

• master == working HEAD of the latest baseline (whatever that is)
• Branch: v2r1 (or the like) for further updates over time once a release has been tagged
• Tags: Base numbering is semantic-style X.Y.Z where X moves with full STIG releases, Y moves with r numbers, and Z moves with routine updates that don't break the interface (parameters, etc...).
  • Full Tags/Releases, would be of the following format:
    • <baseline>-<version>
    • Example: v2r1-0.0.1
  • The reason for this is that we could end up with breaking changes inside of a given STIG baseline to keep up with versions of inspec that break etc...

[trevor-vaughan]

If this is OK, we need to decide where the first tag goes.