XF 2.2 Version ID Format

[Kirby]

I am a bit confused about version ID vs. version string.

According to https://xenforo.com/docs/dev/add-on-structure/#recommended-version-id-format the version ID 2020871 should be

• Major Version 2
• Minor Version 2
• Patch Version 8
• State Stable
• State Version 1

If I use version ID 2020871 on xf-addon:create it does create version string 2.2.8.1, however the download for "XenForo 2.2.8 Patch 1" which uses this ID obviously has a different version string.

It especially seems confusing to me that patch version is 8, yet it is labeled "Patch 1", @Kier @Chris D ?
How does that fit with state 9 (Patch Level), should this be used at all and if so in which cases?

2020891 (2.2.8 Patch Level 1) is higher than 2020873 (2.2.8.3 / "2.2.8 Patch 3") which seems counter-intuitive (or I am missing smth?).

 

[Kirby]

Has anyone figured this out?

 

[Chris D]

Not sure there’s much to figure out?

What we decide to call our versions for the sake of readability is up to us to decide.

Similarly while we generate a version string automatically there’s nothing to stop an add-on developer using their own naming convention.

We’re never going to personally use state level 9 and the number of patches we release will never be more than a couple and for the average customer 2.2.10 Patch 1 is easier to read and understand than 2.2.10.1 so for us a stable version with a state level representing the patch works for us but we do see others using a 4th point version and that may work better for them.

 

[Kirby]

Hi Chris,

thanks four your reply, I really appreciate this.

Not sure there’s much to figure out?

I'd like to understand how to use version IDs correctly.

My current understanding is:

1. Version strings XenForo uses for official releases intentionally differ from those generated by inferVersionStringFromId
2. If there was a hypothetical 9th patch for a released version 1.0.0 XenForo would use version ID 1000079 and version string 1.0.0 Patch 9
3. A version with version ID 1000081 is considered a newer version than 1000070 but older than 1000091
4. This implies that the version string for 1000091 shoud also indicate that it is newer then then version string for 1000081.
   Right now this doesn't seem to be the case, a generated version string 1.0.0 Patch Level 1 doesn't look newer than 1.0.0.11
5. It is therefore not possible to create patch level releases xxxxx9x for version IDs xxxxx7y with y > 0
6. If a patch level version 100009x ("1.0.0 Patch Level y") is released and users of version 1000070 ("1.0.0") upgrade to this version they can't upgrade to version 1000071 ("1.0.0.1") afterwards

Is this correct?

If so I think that the current behaviour and documentation are confusing / inconsistent and I would therefore like to suggest the following changes:

1. Change inferVersionStringFromId so it does handle state 9 as "stable +20" instead of "Patch Level" and that it does output e as Patch e if d is between 7 and 9
2. Update the documentation to include information for states 2, 4, 6, 8 and 9 and refer to e as the build version

This would document all possible states and make the output of inferVersionStringFromId consistent with the use of version strings by XenForo.

 

[Chris D]

How XenForo uses version strings itself makes no difference to how the version string is inferred for the purposes of add-ons.

It obviously isn't recommended to release version xxxxx9y and then attempt to supersede it with xxxxx7y. Version IDs are what matters here, not the version string.

Version strings XenForo uses for official releases intentionally differ from those generated by inferVersionStringFromId

We can use any version string we want. Add-on developers can use any version string they want. The version string we infer makes sense, in the context of the different ways that developers use version strings. If the automatically generated version string is not to your liking, you can change it in addon.json or pass it explicitly in to xf-addon:bump-version.

If there was a hypothetical 9th patch for a released version 1.0.0 XenForo would use version ID 1000079 and version string 1.0.0 Patch 9

Correct.

A version with version ID 1000071 is considered a newer version than 1000070 but older than 1000091

That's how version IDs work, yes.

It is therefore not possible to create patch level releases xxxxx9x for version IDs xxxxx7y with y > 0

Expecting to use version IDs in this way doesn't make sense. It's one or the other. If you want to use the 9 stability for patch releases then do that. If you want to use the 7 stability with a change to the last number then do that. You obviously can't bump the same version e.g. 1.2.1 to have 9 stability then back down to 7.

If a patch level version 100009x ("1.0.0 Patch Level y") is released and users of version 1000070 ("1.0.0") upgrade to this version they can't upgrade to version 1000071 ("1.0.0.1") afterwards

Obviously not. By the numerical nature of version IDs, 100009x is newer than 100007x. So as a developer you simply wouldn't attempt to do that.