FlatBuffers Version 22.9.24

[dbaileychess]

Updated version for new release.

[aardappel]

Woah!

Personally I love this, as I've always said semver is meaningless (for FlatBuffers anyway, where indicating what exactly is "breaking" across so many language implementations you can never get right), and dates are indeed the most amount of useful meaning you can pack into a version.

But I suspect some other maintainers / users may be unhappy with this.. we should gather some feedback before merging this?

[mustiikhalil]

For me, I don't mind the change, since it will make the release process for the swift lib much smoother, however the issue might arise when trying to use SPM with 22.09.14-bc44fad since i'm not sure if that would be accepted within xcode.

ref: https://developer.apple.com/documentation/xcode/publishing-a-swift-package-with-xcode

[dbaileychess]

@mustiikhalil Thanks for the info. The -bc44fad ending is valid semvar (https://semver.org/), so tooling should be able to handle it.

[aardappel]

@CasperN @paulovap @bjornharrtell @krojew @dnfield @vglavnyy

[aardappel]

https://github.com/google/flatbuffers/wiki/Versioning is great.

I'd almost argue to forgo the git hash though.. 2 releases on 1 day is super rare, and if it ever happens, I'd simply use the date of the next day.. by the time the release has perculated thru all package managers etc the date is probably true. And since this date is a version, not used as a real date by package managers etc, there shouldn't be any "date is in the future" errors.

[CasperN]

Are we sure all tooling that we work with will allow semver jumps, e.g. from "22.09.27" to "22.12.12" without going through "22.10.0" and "22.11.0" first?

[aardappel]

I don't see why any tool would require to "see" all consecutive numbers..

Either way, if there is such a tool, we're about to find out with a jump from 2 to 22 :)