Some projects such as ESPHome publish version numbers based on the current year and month, e.g. 2023.05 for the May 2023 update, or 2023.05.3 for the third patch in May 2023 (this is known as Calendar Versioning). However, releases with version numbers in this format aren't picked up by the bot.
In the example of ESPHome, they switched from major.minor.patch to yyyy.mm.patch in 2021, but since the new format isn't recognised by the bot, the Preferred version is still the one from 2021. It would be a laborious task to update versions manually, especailly when there's a bot designed to do it automatically.
I believe that this issue is caused by a regular expression in versionhandler.py: (\s|^)(\d{1,3}(\.\d{1,3})+[a-z]?. The problematic part is \d{1,3} at the start, which means that version numbers that start with more than 3 digits aren't recognised (view on regex101). I suggest updating this to \d{1,4} to support year-based versioning.
Some projects such as ESPHome publish version numbers based on the current year and month, e.g.
2023.05for the May 2023 update, or2023.05.3for the third patch in May 2023 (this is known as Calendar Versioning). However, releases with version numbers in this format aren't picked up by the bot.In the example of ESPHome, they switched from
major.minor.patchtoyyyy.mm.patchin 2021, but since the new format isn't recognised by the bot, the Preferred version is still the one from 2021. It would be a laborious task to update versions manually, especailly when there's a bot designed to do it automatically.I believe that this issue is caused by a regular expression in versionhandler.py:
(\s|^)(\d{1,3}(\.\d{1,3})+[a-z]?. The problematic part is\d{1,3}at the start, which means that version numbers that start with more than 3 digits aren't recognised (view on regex101). I suggest updating this to\d{1,4}to support year-based versioning.