Add-on Update Notifier

Add-on Update Notifier 1.1.8

No permission to download
mazzly updated Add-on Update Notifier with a new update entry:

Added tiers for 90 & 120 extra add-ons to API key

Since it was requested by a few customers to allow more add-ons, we decided to add 2 new tiers..

If you currently have e.g. 60 extra add-ons and choose to upgrade to 120 extra, the remaining days on your current license will be prorated, e.g. 50 days remaining on license @ 60 extra add-ons becomes 25 days remainings @ 120 add-ons + 1 year from that date.

Read the rest of this update entry...
 
This is @Xon fault. The version_string is different to the version_id. These addon work correctly.
 
This.

And even then this addon shouldn't show some half-correct information in these cases.
 
This.

And even then this addon shouldn't show some half-correct information in these cases.
The point of me posting Xon's prior response was to point out that Xon has a justification as to why he cannot update certain add-ons; most of his add-ons are fine, but some are not. Not every case is developer incompetence.

@mazzly is doing an excellent job at offering the update notifications, while also adjusting for any issues with versions or other issues. If you have an issue with how the add-on works, don't use it.
 
Don't like it, don't use it.
lol, nice assumption you did there.

@mazzly is doing an excellent job at offering the update notifications, while also adjusting for any issues with versions or other issues.
Never said otherwise.

If you have an issue with how the add-on works, don't use it.
Oooooor... report the issue as an issue to the add-on developer? Like I just did?

Please stop insinuating.

Edit: lol you even edited your sly post. Nice job.
 
lol, nice assumption you did there.


Never said otherwise.


Oooooor... report the issue as an issue to the add-on developer? Like I just did?

Please stop insinuating.

Edit: lol you even edited your sly post. Nice job.
I removed the first part you quoted, because it was redundant when added at the end 🙃.

He's aware of the issue, however the issue is not something he can do anything about other than to correct it visually and also alert developers, which he does; he even goes as far to give access to developers to handle their own versioning such as he did with @Bob.

Not sure what else you want from him, because god knows he's done more than the other developer did with way less attitude.
 
other than to correct it visually
That's why I reported it. Thanks for explaining.

Not sure what else you want from him
I reported a quirk with the add-on. Whether it's his "fault" or the developers' - I don't care. I see an issue that I, myself, cannot fix, since it's not within my reach - I report it.

because god knows he's done more than the other developer did with way less attitude.
I don't understand why you bring up these arguments - I have never said anything negative about him let alone attacked him in any way, shape or form.

I simply reported a quirk in his add-on. If you want to attack me for that, go on. Have at it. I wish you the most pleasure doing that.
 
This is @Xon fault. The version_string is different to the version_id. These addon work correctly.
The canonical version id for my add-ons is the version_string. As I've explicitly stated before, the version_id handling in XenForo means I can not be changed for most of my add-ons to the format this add-on expects.

Plus the only field that is shown in the admincp? An add-on's version_string and not version_id field. So when parsing fails (and it will fail), it will fail in ways that look silly.

XF's informal version_id schema is fairly restrictive, and the build part simply isn't designed for frequent releases. There are very good reasons why package managers resort to parsing version strings instead of trying to impose formatting rules on an integer id.
 
Is happening again, just now with a different add-on (which was already updated yesterday):

View attachment 283261
Worst case scenario if we can't get this "solved" you can always click "ignore this version" and it won't show up until the next time a release is released of this add-on :)

The canonical version id for my add-ons is the version_string. As I've explicitly stated before, the version_id handling in XenForo means I can not be changed for most of my add-ons to the format this add-on expects.

Plus the only field that is shown in the admincp? An add-on's version_string and not version_id field. So when parsing fails (and it will fail), it will fail in ways that look silly.

XF's informal version_id schema is fairly restrictive, and the build part simply isn't designed for frequent releases. There are very good reasons why package managers resort to parsing version strings instead of trying to impose formatting rules on an integer id.
I'm not 100% sure I understand the reason that e.g. the Alerts Improvements package could not be released with version_id: 2090000 which would match the version_string: "2.9.0", now it is released with version_id: 2090011 which is the same as version_string: "2.9.0 Alpha 1".
  • If your own/legacy add-ons check version_string for the actual version, then that can be kept "as is" and you just put version_id to be the matching value.
  • If your add-ons use version_id, then just release the add-ons on XF with a version_string that matches the actual version_id
But I trust there is a reason for this, and I'm missing some point that would explain it :)
 
The XF add-on installer code requires the version_id increase to trigger template/phrase import/rebuilds. My private deployment pipeline means I will often deploy multiple versions (ie they require the version_id to be incremented) before the final release.

I've been meaning to migrate the version_id to being automatically set using a unix-timestamp on build, simply so the version_id is always being increased automatically without needing a complex schema of what an int should look like.
 
Last edited:
The XF add-on installer code requires the version_id increase to trigger template/phrase import/rebuilds. My private deployment pipeline means I will often deploy multiple versions (ie they require the version_id to be incremented) before the final release.

I've been meaning to migrate the version_id to being automatically set using a unix-timestamp on build, simply so the version_id is always being increased automatically without needing a complex schema of what an int should look like.
That makes sense. :) 👍

However, couldn't you bump the number one last time before making the release? In the above case with "Alerts Improvements" you could've bumped it to version_id: 2090070 which matches version_string: "2.9.0"... 🤔
 
Another potential issue (if I'm still allowed to report them @Forsaken?)

1679643768224.webp

When an add-on is "upgradeable", aren't the files already replaced? So it'd make sense to hide the "Download"-button there, wouldn't it?
 
Top Bottom