version number is a little bit confusing

[trim21]

looks like it's year.month.monotonic, why monotonic after major and minor part is already year and month?

[rmartin16]

Yeah....I won't disagree it could be confusing. This scheme is a bit bespoke. I didn't really want to go with semantic versioning since I never intended to have breaks in compatibility. I think I considered the monotonic part to be a build number or a single number unique to the release. If I could do it again, I'd probably just do YY.MM.patch where patch would normally be 0.

[trim21]

maybe just use date, for example, 2024.11.17

[rmartin16]

Right, I think that would be reasonable. In fact, when the monotonic part was below 30, it definitely just looked like a date...but wasn't. My only quibble, I think, with a day number is it's technically ambiguous. At any one moment, it is always two different days on the planet. This can easily be solved by using the day from UTC but the ambiguity remains. That said, this ambiguity would rarely ever be important sooo... Maybe I'll consider a new years day release with the date or something.

[trim21]

I think just use your local tz would be fine.

Will any one would really parse that number back to date and think about tz of it? If someone need date of any release, normally they will just use metadata provided by github (tag/release) or pypi.

At least I never did that when I saw date in black's version number.