I follow something similar for versioning of our closed-source libraries. We need to have release numbers due to corporate rules, but they don't enforce SemVer, so we switched to CalVer instead (calver.org). It works great because we never have to think which number we increase and the version number always increases, so all the version comparing tools work.
It doesn't work very well if you maintain multiple lines of a project. I'm thinking of some bigger projects, let's say Django devs find some security issue. They can add it to the latest version, but a lot of devs still run version 2.6 and they can't upgrade to 3.0 immediately, so Django team releases 2.6.1 and 3.1.2 independently.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I follow something similar for versioning of our closed-source libraries. We need to have release numbers due to corporate rules, but they don't enforce SemVer, so we switched to CalVer instead (calver.org). It works great because we never have to think which number we increase and the version number always increases, so all the version comparing tools work.
It doesn't work very well if you maintain multiple lines of a project. I'm thinking of some bigger projects, let's say Django devs find some security issue. They can add it to the latest version, but a lot of devs still run version 2.6 and they can't upgrade to 3.0 immediately, so Django team releases 2.6.1 and 3.1.2 independently.