Plugin Versioning numbers

[un_pogaz]

Originally Posted by DrChiper

As "Release/Major/Minor" is pretty vague, I would suggest:

Feature Release, Feature Enhancement, Feature Fix, Experimental

This will help on determination when some value needs to be bumped-up.

So, although the vast majority of developers have agreed to use a versioning with three number in a vaguly Release/Major/Minor, regarding about the exact meaning of each of its numbers and when increase them... weelllllll, good luck with that: nobody agree on this.
And I realy don't want see or start such debat because it would be a wild hell that will fly very low and very hard.

[DrChiper]

Originally Posted by un_pogaz

So, although the vast majority of developers have agreed to use a versioning with three number in a vaguly Release/Major/Minor, regarding about the exact meaning of each of its numbers and when increase them... weelllllll, good luck with that: nobody agree on this.
And I realy don't want see or start such debat because it would be a wild hell that will fly very low and very hard.

Never dreamed to encounter such a moodily reply on just a suggestion. Did I touched a soft (version) spot? By all means, take the floor and enrich us by your wisdom.

[theducks]

Originally Posted by DrChiper

As "Release/Major/Minor" is pretty vague, I would suggest:

Feature Release, Feature Enhancement, Feature Fix, Experimental

This will help on determination when some value needs to be bumped-up.

Release = Not 100% backwards compatible. eg, like, database structure changes that older version will fail (hopefully, gracefully without damage) on.

Major = ?? New features, Just not supported earlier on in the same release.

[BetterRed]

Originally Posted by PeterT

Any thoughts on standards / techniques that could be implemented to handle these issues?

I don't have much to add, that hasn't already been said.

I don't interpret or attach any significance to version numbers, providing they are orderly. I don't like cute names. Aside: why has there never been a MacOS Esalen.

All I ask is that temporary (experimental, beta, whatever…) versions should not be left lying around in Plugin thread replies if they are superseded by an official or another temporary version. If they can't be removed by the originator for some reason they should report the offending post, or PM a calibre mod with a request they be removed.

---

Originally Posted by JimmXinu

. . .

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.

Curious, who 'owns' the Semantic Versioning 2.0.0 document, which has this:

As a solution to this problem [dependency hell], we propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented.

So, who is 'we'… We the people, the royal We, Zemyatin's We

[kovidgoyal]

4 version numbers *might* work, but they haven't been tested. My recommendation is stick with three, community updates (not in first post) should bump the last of the 3 numbers. When an official release of the plugin (first post) is made it should use a 3rd number larger than the community ones or bump the 2nd number.

[kiwidude]

I'm not really understanding what the issue is here to spark all this discussion, but my personal approach as an official author/maintainer is to just make sure I use a number higher than whatever else is out there on the thread in the rare circumstances this happens.

If my last official release is x.y.9 and someone posted an unofficial x.y.10 build on the thread then I would just make my next version x.y.11. Does that mean a gap in the release notes number sequence - sure, but it doesn't matter in the slightest. Would an x.y.9.1 build number by them be a cleaner option - sure, but I'm not going to jump all over someone for using x.y.10 instead. These circumstances (on my plugins at least) are so incredibly rare where someone is posting another build on one of my threads that it's just not worth debating imo.

In my day job - absolutely I have very strict approaches, stick to semantic versioning with major.minor.build.revision etc. But for plugins I am way more casual about it - 0 or 1 for the first number to indicate a not yet released alpha of new plugins vs a released one, the second digit for major feature releases/rewrites such as python version changes, and the third digit for bug fixes/minor new features. Would the sky fall in if I broke my own "rules" just to make sure my next official build has a bigger number than an unofficial one on a thread? No.

[DNSB]

Originally Posted by BetterRed

Curious, who 'owns' the Semantic Versioning 2.0.0 document, which has this:


So, who is 'we'… We the people, the royal We, Zemyatin's We

The Semantic Versioning specification was originally authored by Tom Preston-Werner, inventor of Gravatar and cofounder of GitHub.

If you look at the GitHub site for semver, you will see seven people listed. If you go to the repository, you will see 38 people listed who have contributed. I would suspect those 38 are the "we".

[BetterRed]

I guess I'm old school, I would have written

As a solution to this problem [dependency hell], a simple set of rules and requirements is proposed that dictates how version numbers are assigned and incremented.

That is, drop the personal pronouns, it's not an opinion piece in the Betoota Advocate

[un_pogaz]

@DrChiper My reply was more on a humor tone that any things. Truly, the subject is half serious, don't mind it.

@BetterRed Hence the advantage of the semantice with four number for randomly shared version of a plugin. That mark it in the changelog that the user use a non standard version. Obviously, is even better that user that originaly share the hacky version delete it after their usage is ended, but second adavantage of four number version: Their don't interfer with official one that can take priorité of any hacky version that the user had installed.

@kovidgoyal Agree. 4 version numbers is just temporary version, preview, test, edit suggestion, etc. It work fine but it also inherently instable and unsuported. At the end, a official version with only 3 number need to be release and that the only one that we need to take care, even if it maintain by the community.
Pratical example: Right now, a user curently report a bug with my plugin, and I share a 4 version numbers to see if I corretly identifier and fix the bug their enconter before deploy the official one with only 3 numbers version.

@kiwidude Probably your own Quality Check plugin thread, wich one a user share a fix version for Calibre 8.12, but had not changed the number version of his mod, creating a risk of misidentify if is a official version instaled or the altred one in any future bug report.
Also, to clarify, for me a "official" version is the one in the attached to the first post, regardless of if is the orignal author or a maintener who build it, and so the only one that Calibre will search and use. See the others paragraphe/reply above.

[DrChiper]

Originally Posted by un_pogaz

@DrChiper My reply was more on a humor tone that any things. Truly, the subject is half serious, don't mind it.

No hard feelings; consider the case as closed.

[DrChiper]

What I miss in the above discussions is how to guarantee that the community code changes find their way back in the main branch of of the source code of the original developer/maintainer. When that developer/maintainer has already made changes without some official release yet, how can we make sure the temporary community fixes do not get lost or even break existing code?

[JimmXinu]

Originally Posted by DrChiper

What I miss in the above discussions is how to guarantee that the community code changes find their way back in the main branch of of the source code of the original developer/maintainer. When that developer/maintainer has already made changes without some official release yet, how can we make sure the temporary community fixes do not get lost or even break existing code?

The short answer, IMO, is there are going to be no guarantees.

Calibre plugins are informal, volunteer development, without uniform methodology. It's a hobby, not a job.

My personal takeaways are:

• Continue with 3 number only versions. 4 might appear to work, but it's untested and unapproved.
• Bump at least the minor (vs micro/patch) number for plugin releases and use micro/patch number for unofficial and test versions.

Basically, what I've already been doing. So no surprise I like it.

I should have handled the versions for ME/QC/GrS better; that's on me. It was more of a mistake in haste than a conscious decision. However, I don't think it's a big enough deal to go bump and release again.

While I agree with BetterRed in general that superseded plugin zip files should be removed, I don't see it as a 'report to mods' offense.

For example, JSWolf PM'd me about releasing his version of Hyphenate This! (OP appears MIA) and my first thought was to save the prior version in a post, since there's no source repo link.

[theducks]

Originally Posted by JimmXinu

While I agree with BetterRed in general that superseded plugin zip files should be removed, I don't see it as a 'report to mods' offense.

Report to Mods (greenies) is not just for bad actors. It is also when action is needed that can't be accomplished by the normal user.
IMHO it is better to use a PM to Forum Level mod (list at the bottom of the main forum) when possible, taking a bit of workload off the Greenies.

If the request is controversial, We (forum level) might bump it up.
FWIW Just because a request comes in to add/update a PI, will I act. Especially if the user does not have any track record here at MR. I am not qualified to detect a possible damage causing PI. I leave those approvals to more qualified developer mods.