Check Add-On update Thread

Until XenForo.com strictly enforces semantic versioning during resource submissions a "Check Add-on Update" resource will not be very useful and the amount of complaints and disgruntled users will be never ending.

If the Check Add-On Update resource misses just one or two resource updates out of a bunch it will still require the admin to go searching for updates and make them wonder how many others it may have missed, completely missing the point of the add-on to begin with.

XenForo.com must add a new "Semantic Version" option to its' resource submission form. This option must strictly enforce the semantic versioning specs. They are pretty simple to follow and anyone who has coded a resource should not have trouble figuring it out quickly.

Resource submitters can name the resource "version" anything they want but the actual "semantic version" submitted for the resource must follow the specs so a version checking add-on can work as well as it should.


semver.webp
 
Until XenForo.com strictly enforces semantic versioning during resource submissions a "Check Add-on Update" resource will not be very useful and the amount of complaints and disgruntled users will be never ending.

If the Check Add-On Update resource misses just one or two resource updates out of a bunch it will still require the admin to go searching for updates and make them wonder how many others it may have missed, completely missing the point of the add-on to begin with.

XenForo.com must add a new "Semantic Version" option to its' resource submission form. This option must strictly enforce the semantic versioning specs. They are pretty simple to follow and anyone who has coded a resource should not have trouble figuring it out quickly.

Resource submitters can name the resource "version" anything they want but the actual "semantic version" submitted for the resource must follow the specs so a version checking add-on can work as well as it should.


View attachment 278603
There shouldn't be a need to enforce a specific standard as long as you can compare versions on the proper page; the issue with the other add-on is that he was not doing that, and was also not supporting shorthand (which is part of almost every versioning standard).
 
It’s not as easy of a task as it seems on the surface, there are a lot of nuances that hinder a fully functional version checking addon.

Understandable. However, what he had worked better than nothing.

Thing is, XF does not have a way realistically to monitor updates, even by the XF website. So when you have 10 or 20 or more addons, how do you check for updated addons? It's a PITA and things often don't get updated. The addon that was there at least got many of the more common addons.
 
Until XenForo.com strictly enforces semantic versioning during resource submissions a "Check Add-on Update" resource will not be very useful and the amount of complaints and disgruntled users will be never ending.

If the Check Add-On Update resource misses just one or two resource updates out of a bunch it will still require the admin to go searching for updates and make them wonder how many others it may have missed, completely missing the point of the add-on to begin with.

XenForo.com must add a new "Semantic Version" option to its' resource submission form. This option must strictly enforce the semantic versioning specs. They are pretty simple to follow and anyone who has coded a resource should not have trouble figuring it out quickly.

Resource submitters can name the resource "version" anything they want but the actual "semantic version" submitted for the resource must follow the specs so a version checking add-on can work as well as it should.


View attachment 278603
Yeah, this is honestly the "biggest problem"... The CLI command to bump versions is not really user-friendly and when you write a "wrong" number it allows the developer to also put whatever version string they want... (Contrary to popular belief, developers are also users/human) :D

If you do it correctly XF handles it magically:
1671517542673.png
But if I write a number that is not within 1000000 and 99999999
Screenshot from 2022-12-20 08-26-25.png
This is bad because it allows the addon devs to manually write something that doesn't match the number... Instead, it should enforce the "standard way" by default, and if some addons dev doesn't like that they should explicitly have to circumvent it by using a flag like --non-standard-version so that we really "force" devs to use the format that XF expects..

Then there is still another problem:
When addon devs upload the version, some of them manually write the version string into the "New version number-field", which gives a risk for typos... The best way to avoid this would be that they copy-paste the string from addon.json so that it is surely correct :)

It’s not as easy of a task as it seems on the surface, there are a lot of nuances that hinder a fully functional version checking addon.
Yes exactly... I started some work on the backend to check versions etc this Saturday and there are quite a few things that need to be taken into account 😅 The previous addon was to trivial in it's checking and just checked the version_string, which can be whatever the addon dev writes (see above)

I currently have a list of ~2300 addon IDs and likely their latest versions (these also include some private addon IDs that will likely never be published/checked)... Of these, there are ~1000 that have an XF resource URL...

For like 90% of the ones I scraped, the number matches fine... Then for others, there are mismatches in the latest version... of these about 50% are due to the addon dev just writing whatever they want into the version string field (i.e. mismatch of version_id and version_string in the addon.json when downloading to check the addon package..)
  • What this tells me is that we also have an "education problem", where it is too hard for some addon devs to know how the versioning works, and doing a mistake you might bump it too much (yeah I know you can revert with --force but they don't...). Due to this some addon devs just write a slightly higher number than last version, and then when releasing write "what they would want it to say"..
    • So the addon will also need to have some type of helper for this so that addon devs don't have to sweat about how to write the number correctly :) Luckily I already have something in mind for this ;)
Understandable. However, what he had worked better than nothing.

Thing is, XF does not have a way realistically to monitor updates, even by the XF website. So when you have 10 or 20 or more addons, how do you check for updated addons? It's a PITA and things often don't get updated. The addon that was there at least got many of the more common addons.
This won't be a problem for long... We are working on this and as soon as I can get my backend somewhat ready we can release an addon that does the same thing (but better) ;)
 
Semantic versioning is useful in theory, but very very hard in practice. Not to mention not all add-ons actually follow that policy.

But simple-ish version checking can be semi-reliably done, and patched over time to account for weirdness.
 
What this tells me is that we also have an "education problem",

addon dev just writing whatever they want into the version string field (i.e. mismatch of version_id and version_string in the addon.json when downloading to check the addon package..)
that's what I've been writing and complaining about all along. YOU call this now "Bildungsschwach" I may have called it "Incompetent". But fact is: Your titling does not make it better and you stand now before the same problems for which I was hostile. Quite funny.

The thing you accused me of - I should just change it; Seems like it's complex after all. May not have always hit the right words - but in the end it is what it is.

Well then good luck!
 
that's what I've been writing and complaining about all along.
No... You complained to devs that were actually doing it the correct (XF recommended) way... Big difference there :)

The thing you accused me of - I should just change it; Seems like it's complex after all. May not have always hit the right words - but in the end it is what it is.
Yes of course we will have to adapt to easy things like e.g. Andy's addons that are using slightly different versioning, but his versioning at least matches both version_id and version_string to have values that match :)

What I'm talking about above are devs that write totally different numbers into the version_id and version_string-fields...
A very good example of this that I ran into when parsing addon versions vs what the version actually was was one where they had:
  • "version_id set to 1000447 which would be "1.0.4 (non-existing value between Alpha/Beta) 7"
  • "version_string was set to 1.0.0 Beta 9 ... :D
That's quite a big mismatch if you ask me...

Well then good luck!
Thanks :) 👍
 
The version_id is a design defect for XenForo's version handling. XF should have enforced a standard format for version_string (ie doesn't allow installing the add-on if it doesn't match), and dropped version_id.

There is only one place which requires an integer 'is greater' check, and that is the upgrader preventing downgrades (unless forced). But that can be replaced with version_compare() function call on version_string.

Every other use of the version_id is just a simple equality/inequality check which can be trivially replaced with using version_string instead.

What I'm talking about above are devs that write totally different numbers into the version_id and version_string-fields...
XFMG actually does something like this.
JSON:
    "version_id": 902020470,
    "version_string": "2.2.4",

This is an artifact of version_id needing to always be greater, to cleanly upgrade and sometime mistakes being made.
 
The version_id is a design defect for XenForo's version handling
According to you, or have they confirmed that? 🤔 (Thinking if they are planning to change it?)
XF should have enforced a standard format for version_string (ie doesn't allow installing the add-on if it doesn't match), and dropped version_id.
That I agree, except they should have actually dropped the version_string which could easily (and is when used correctly) be generated from the version_id number :D
XFMG actually does something like this.
Yep saw that, along with a bunch of other addons (Roughly ~70 in my list of ~2k addons)... There has to be a reason for the 90-prefix, as there are quite a few, and they actually have the correct version/matching if you remove the 90-part... 🤔
 
Could it be so the XF1 addons with the same addon ID can be upgraded? (I'm assuming the XF2 version would have a lower version number than the XF1 one)
I was thinking that at first also, but Bob sent a PM and apparently it was a way to "fake bump down" the version when it e.g. got too high 😊👌
 
I think that what would be a good idea is that addons tie their major version to the same as XenForo. eg. version 1.6.12 can only be installed on a compatible 1.x.x version of XF, 2.5.x can only be installed on a compatible version of XF 2.x.x. Addon authors may already follow this convention but I feel that we this addon and with proper engagement of addon authors we could be onto defining a standard moving forward which hopefully the XF devs will have input into.
 
According to you, or have they confirmed that? 🤔 (Thinking if they are planning to change it?)
Having two fields (one which is a free-text field) for the same thing is just bad developer UX.

I feel it is unlikely they'll change it any time soon.

I think that what would be a good idea is that addons tie their major version to the same as XenForo. eg. version 1.6.12 can only be installed on a compatible 1.x.x version of XF, 2.5.x can only be installed on a compatible version of XF 2.x.x. Addon authors may already follow this convention but I feel that we this addon and with proper engagement of addon authors we could be onto defining a standard moving forward which hopefully the XF devs will have input into.
Due to how XenForo's version_id/version_string mess works, this isn't viable to change for a number of existing add-ons.

The addon.json just doesn't encode enough information to support a maximum supported version for things.
 
Last edited:
While XF does have some tooling around version handling; the CLI command xf-addon:bump-version is not terribly useful.

Run without a version argument, it prompts for a unformatted int based version_id which you need to manually build from from the add-on's existing version string just so it can attempt to build a version string for you. It doesn't actually bump the version either, and doesn't understand semantic versioning.

The version "1.2.3 patch 10" can't actually be encoded with CLI tool, and I've had legitimate reasons to need that.

Given most releases are just going to be patching a single digit in version string, you might as well edit the addon.json directly and run xf-addon:sync-json or xf-addon:upgrade. And running the upgrade is often preferable as it runs the upgrade steps.

If you have multiple developers working on the same code-base, you will absolutely need to get used to using xf-dev:import --addon="My/Addon" since the hot-reload detection only works for templates (sometimes) and fails utterly for everything else in My/Addon/_output at which point throwing in xf-addon:sync-json cli calls is trivial.
 
Last edited:
Back
Top Bottom