Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible [addon] changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
I wish more addon developers follow that format but some donβt. So each time I download an update I put the date instead so I know which one is newer. Like SuperTurboMultiDraw_27_Feb_19.zip
(And I bought loads of addons on eh, Blender Market so instead of earning I helped those guys there to have their job. But I think I am going to support other markets as well. ).
I think that keeping it simple and concise both for you and for your users is a good idea.
I used to just use regular numbers with fractions now I am leaning more towards actually adding the release date to the version, that way we all know when also the addon is released.
To me MyAddon_1.2_20190228 is a better release version than say MyAddon_1.003.76 The only issue with is that Blender bl_info does not like that so at least we can name the zip files with the dates.
3 numbers
1st major update - many new features and bug fixes
2nd minor update - few features and bug fixes
3rd tiny update - only for small critical bug fixes
my workflow is that all numbers should be sequential apart from the last one
the last is an equivalent of 2.79a , 2.79b etc.
I prefer to use the first one as 1 unit per year, second for around a 1 unity per month. But overall its not that important. My advice if you dont expect very frequent updates avoid the 3rd number unless you want to do this like Blender.