Check Add-On update Thread
- Thread starter Ozzy47
- Start date
bzcomputers
Well-known member
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.
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.
Forsaken
Well-known member
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).
Joeychgo
Well-known member
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.
mazzly
Well-known member
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)
If you do it correctly XF handles it magically:
But if I write a number that is not within
1000000 and 99999999 
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 
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
--forcebut 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
- 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
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)
Just watch them with e-mail notifications.
D
Deleted member 232995
Guest
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!
mazzly
Well-known member
No... You complained to devs that were actually doing it the correct (XF recommended) way... Big difference there
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_idset to1000447which would be "1.0.4 (non-existing value between Alpha/Beta) 7""version_stringwas set to1.0.0 Beta 9...
Thanks
The
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
Every other use of the
This is an artifact of
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.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.
mazzly
Well-known member
According to you, or have they confirmed that?
(Thinking if they are planning to change it?)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 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...
benFF
Well-known member
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)
mazzly
Well-known member
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
Deebs
Well-known member
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.
Joeychgo
Well-known member
that ends up being just a mess for me, especially considering I have multiple sites... Not to mention its extra steps. This addon solved many of those issues for me and was extremely helpful. I'm hoping we can get something similar up and running soon.
mazzly
Well-known member
Yeah I don't think you'll have to wait too long
Joeychgo
Well-known member
Yeah I don't think you'll have to wait too long
great to hear!
Having two fields (one which is a free-text field) for the same thing is just bad developer UX.According to you, or have they confirmed that?
I feel it is unlikely they'll change it any time soon.
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
Run without a version argument, it prompts for a unformatted
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
If you have multiple developers working on the same code-base, you will absolutely need to get used to using
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:
Similar threads
- Question
