View Single Post
Old 10-05-2025, 12:20 PM   #3
JimmXinu
Plugin Developer
JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.JimmXinu ought to be getting tired of karma fortunes by now.
 
JimmXinu's Avatar
 
Posts: 7,104
Karma: 5005503
Join Date: Dec 2011
Location: Midwest USA
Device: Kobo Clara Colour running KOReader
All three are integers in code and, as I recall, adding letters will break comparison types when checking which is newer.

My approach is to increment the middle (minor) number for regular releases and to increment the right most (micro or patch) number for test versions or emergency bug fix releases. Community posted versions could also bump micro.

I should have bumped the ME/QC/GrS micro version by 2, or bumped the minor version; I honestly didn't think about it until after I'd already released ME.

FYI, semi-related, Github releases want Semantic Versioning (https://semver.org/) these days. Which does allow for extra specificity after the micro number, but doesn't want anything before the version number. To the point that I've found I have to use "Name 1.2.3" when naming releases because using "Name v1.2.3" can cause github to list releases out of order.

And I do acknowledge that I put out FFF test versions more frequently than most plugins, and that using the micro number for that violates Semantic Versioning rules. We work with what we have.
JimmXinu is offline   Reply With Quote