Stricter versioning?

[mxmCherry]

Hey,

Today I've found something interesting: 5a6aac5

Basically, List: Lost Reason Codes enum was shifted by one item in the middle.

And this is reflected in Change Log

Though version is not bumped - it's still 3.0, which surprises me (I consider such change not being back-compatible).

IMO such changes without version bump may prevent exchanges from adopting and fully adhering to the spec.

I understand that it's just a Loss Reason codes to be used in macro (like, it's not the "core" enum used in object props etc), but if spec defines such enum - I'd expect it to be more "stable".

Or is this spec supposed to be versioned not like 3.0, 3.1 or 3.0.1, but like 3.0 November 2018, 3.0 June 2020 etc?

I'd really love if this (reminding - supposed-to-be-industry-standard) spec would be versioned in a more strict way (I'd prefer semver).

[SyntaxNode]

@hillslatt Could we use the same month and year based versioning for OpenRTB 3.0 as we are now using for OpenRTB 2.6?