No, don't do this. You're concerned about information loss, but without semver the consumer doesn't know if a major change occurred that would break their build

No, don't do this. You're concerned about information loss, but without semver the consumer doesn't know if a major change occurred that would break their builds. Software vendors and consumers do NOT want automatic major version bumps on Jan 1st. They DO want control over when a major version is released and when they update to it. Using 2022-06-11 as your version, do you hold all your major breaking changes for Jan 31st? That's impossible. You get all those "Pros" by working within Semver and appending the date to the patch part: major.minor.patchyearmonthday Edit: To support version parsers always expecting only 3 version numbers I removed the dashes in the example.