XF 2.0 Does it matter if the legacy addon's version string is different?

[DragonByte Tech]

For our XF1 addons, I decided it would be incredibly clever to use YYYYMMDD as the version string rather than the recommended version format. For the XF2 versions, I've switched to the recommended format.

Will this cause any problems when users upgrade from XF1?


Fillip

 

[Mike]

Provided your new version strings are larger numbers than your old ones, no. If they're smaller, that will be problematic as it will be seen as a downgrade.

 

[Chris D]

Mike is correct, assuming you meant version IDs rather than version strings.

FWIW we remedied this in XFMG 1.x (when we brought it over as an official XF add-on) by prefixing the version IDs with 90.

So version 2.0 would be 902000070 etc. which should always be a larger number than any of your current ones.

e.g. 20161231 will always be higher than the recommended ID with a 90 prefix.

 

[DragonByte Tech]

Mike is correct, assuming you meant version IDs rather than version strings.

I did, yeah

FWIW we remedied this in XFMG 1.x (when we brought it over as an official XF add-on) by prefixing the version IDs with 90.

So version 2.0 would be 902000070 etc.

Fair enough, I guess that's what I have to do as well then. I wasn't sure whether it being a legacy addon would mean the version ID would be ignored, and it was just assumed the DB was identical.

Thanks!


Fillip

 

[Chris D]

We have a cool thing with the xf-addon:bump-version command. If you type in the next version ID in the "recommended" format, e.g. 2000034 then it will automatically infer the version string as "2.0.0 Beta 4" from that and you don't have to type the version string.

However, it didn't recognise the version IDs with the 90 prefix. Well, it does now So if you enter a version ID of 902000034 it will automatically infer that the version string is "2.0.0 Beta 4".

 

[AndyB]

If they're smaller, that will be problematic as it will be seen as a downgrade.

What if an admin would like to downgrade an add-on in XF2, is it possible? So for example on a XF2 forum we have an add-on that is version 15 and the admin would like to downgrade to version 14 of the add-on, will it be possible to do that?

 

[Chris D]

Nope, that will almost certainly never be possible.

 

[Liam W]

What if an admin would like to downgrade an add-on in XF2, is it possible? So for example on a XF2 forum we have an add-on that is version 15 and the admin would like to downgrade to version 14 of the add-on, will it be possible to do that?

No. Downgrades are never really possible, as to rollback database or data changes would require work that doesn’t really make sense to do.

Liam

 

[Jake B.]

However, it didn't recognise the version IDs with the 90 prefix. Well, it does now So if you enter a version ID of 902000034 it will automatically infer that the version string is "2.0.0 Beta 4".

A lot of the add-ons we've inherited from Jon use a Unix timestamp as the version id so prefixing the version id with 90 still won't help, will this change recognize a prefix of any length, or only one of '90'? Alternatively, would there be a way to bypass the requirement of the version id being greater for upgrading from a legacy add-on? Perhaps having a legacy_max_version so it won't try to upgrade from a version that it's actually not supposed to upgrade from. I prefer using the same version id format as XF does (and it's what most of our add-ons use that weren't inherited) and I'm not sure I'd remember to include that prefix when running the bump version command

 

[AndyB]

Nope, that will almost certainly never be possible.

In XF1 it was possible, why is it not possible in XF2?

 

[Jake B.]

In XF1 it was possible, why is it not possible in XF2?

I don't believe it was

 

[Chris D]

A lot of the add-ons we've inherited from Jon use a Unix timestamp as the version id so prefixing the version id with 90 still won't help, will this change recognize a prefix of any length, or only one of '90'? Alternatively, would there be a way to bypass the requirement of the version id being greater for upgrading from a legacy add-on? Perhaps having a legacy_max_version so it won't try to upgrade from a version that it's actually not supposed to upgrade from. I prefer using the same version id format as XF does (and it's what most of our add-ons use that weren't inherited) and I'm not sure I'd remember to include that prefix when running the bump version command

I don't think we'll be doing anything more here.

The other option would be for you to essentially re-release the add-on with a different add-on ID, version scheme etc.

You'd just have the installer of the new add-on migrate any data it needs to migrate, remove the old add-on entry etc. Bit long winded, but I don't think it's feasible for us to include a system that can cater for all issues.

In XF1 it was possible, why is it not possible in XF2?

I don't believe it was

It definitely wasn't possible.

If I recall correctly, you spent several years releasing your add-ons with a version ID of 1 and never changing it. It would be possible to downgrade from version 1.1.0 (version ID 1) to 1.0.0 (version ID 1) because it is the version IDs which are used for comparison, not the strings.

 

[Snog]

A lot of the add-ons we've inherited from Jon use a Unix timestamp as the version id so prefixing the version id with 90 still won't help, will this change recognize a prefix of any length, or only one of '90'? Alternatively, would there be a way to bypass the requirement of the version id being greater for upgrading from a legacy add-on? Perhaps having a legacy_max_version so it won't try to upgrade from a version that it's actually not supposed to upgrade from. I prefer using the same version id format as XF does (and it's what most of our add-ons use that weren't inherited) and I'm not sure I'd remember to include that prefix when running the bump version command

There is a simple way around this that I'll probably get jumped on for suggesting.

Issue a required add-on for Jon's add-ons that changes all of the add-on IDs to say 100 in the XF 2 add-on database. Or, some such other method to change the IDs en-masse in XF 2. You can then use the recommended version format for updates.

I used this method manually for add-on version check tests in XF 2 without a problem.

 

[AndyB]

If I recall correctly, you spent several years releasing your add-ons with a version ID of 1 and never changing it. It would be possible to downgrade from version 1.1.0 (version ID 1) to 1.0.0 (version ID 1) because it is the version IDs which are used for comparison, not the strings.

Correct, I always used version ID 1 for all my add-ons in XF1 and that would explain why it was possible to downgrade my add-ons because the version ID always remained the same.

 

[Jake B.]

I don't think we'll be doing anything more here.

What about supporting a longer prefix than 90 to support add-ons that had a longer version ID (assuming it isn't already supported)

Issue a required add-on for Jon's add-ons that changes all of the add-on IDs to say 100 in the XF 2 add-on database. Or, some such other method to change the IDs en-masse in XF 2. You can then use the recommended version format for updates.

I considered doing this, but it just seems like extra, unnecessary hassle. Will probably just go with it being a new install that migrates the data and removes the previous add-on

 

[Chris D]

What about supporting a longer prefix than 90 to support add-ons that had a longer version ID (assuming it isn't already supported)

Wasn't really keen on the idea but it doesn't hurt. You can now prefix the typical version ID format by 90 up to four times if you need more length, e.g. all of the following will be inferred as version 2.3.4:

• 2030470
• 902030470
• 90902030470
• 9090902030470
• 909090902030470

 

[Snog]

Nothing like covering all the bases. I think 2 was probably all that was needed, but if someone wants more now there's something wrong with their version scheme to begin with.

 

[Jake B.]

I don't think 9090902030470 or 909090902030470 would work anyways as version_id is an unsigned integer so it's limited to a max value of like 4.2 billion

 

[Chris D]

Well, you know, there was me thinking 90 would be more sufficient, but that was quickly proved wrong... @Jake B.

I just know that if I didn't add at least one extra level, one of you guys would come out of the woodwork and say you currently use a unix timestamp in milliseconds or something

I don't think 9090902030470 or 909090902030470 would work anyways as version_id is an unsigned integer so it's limited to a max value of like 4.2 billion

Like that would stop people! Probably find people who have changed all the core version_id fields to BIGINT to accommodate it

Jokes aside, yes, the current detection is way over the INT limit in MySQL but a bit of future proofing never hurt anyone

 

[Jake B.]

Well, you know, there was me thinking 90 would be more sufficient, but that was quickly proved wrong... @Jake B.

I just know that if I didn't add at least one extra level, one of you guys would come out of the woodwork and say you currently use a unix timestamp in milliseconds or something

All of our new add-ons change version_id to a blob and add a new digit of pi on each update