Package Maximum Compatible Backfill

[digital drum]

Discuss!

[fathom wraith]

Thanks for filling the data!

[heady shadow]

The example that has end result like this:

0.2.2 | Maximum 9
0.3.0 | Maximum 10
0.3.1 | Maximum 10

I feel should have 0.3.0 filled as max 9

Foundry has only solid proof that max was upgraded to 10 With 0.3.1, not prior.

Versions with no prior max obviously diverge from this.

[native latch]

I shall be writing my congressman forthwith!

[gentle frost]

I think I disagree, because the developer of such a module most likely only bothered to set the "maximum" on the latest release, assuming users are all using that version

[heady shadow]

Users already on that version are unaffected by the setting tho (mostly).

Also, you can easily also read it as being lazy to update since the previous stated max is still in effect (the previous max is still in effect, so why state it again).

[gentle frost]

To prevent this from needing to happen again, I suggest adding something to the package admin version config section that reminds users to backfill maximum versions (ideally only have it show up if they try to add a maximum version where is was blank for others above it)

[heady shadow]

Make it required field for all but the newest.

[digital drum]

There are potentially valid use cases (although they are rare) when an older version might have no maximum but a newer version does.

[heady shadow]

They could enter 999 then :p

[digital drum]

that is not allowed

[heady shadow]

Really? Huh. Well, it's I guess fine. Just show a warning that the missing value might cause problems.

[zenith pawn]

Doesn't the directive to minimise use of max in the future mean that this can happen again? Currently blank, but then when a breaking change arises, adding a max?

[digital drum]

Yes. We have not implemented a "solution" that prevents this same situation from happening again. Package metadata can be mis-configured. Most of the misconfigurations were legacy issues dating back to eras of the software which predated even the existence of a maximum compatibility field.

We are going to monitor the situation and decide (later) whether further changes are necessary here. We want to trust package authors to configure their own metadata.

Our recommendation is that a maximum version should not be declared until a compatibility issue is known rather than pessimistically declared in anticipation of a potential issue. This should be a developer-specific choice though rather than a requirement.

[night agate]

I think part of the situation is that maximum didn't exist prior to V10. Backfilling is needed because anything prior to that had no concept of max at all

[digital drum]

I believe it was added in v9, but you may be correct.

[night agate]

Could be. My memory is a bit fuzzy that far back, lol

[heady shadow]

Max was added with compatibility field, and I'm pretty sure that's v10 thing. No: See below

[verbal abyss]

The main reason to declare maximum version is that we are doing this mostly free and with our free time. We don’t usually have time to respond to every discord message when a system doesn’t work in new Foundry version. So it is more about avoiding angry crowd than pessimism.

[ebon otter]

maximumCoreVersion existed in v9.

[weary sigil]

usually something big has changed between major versions so mostlikly a module breaks when running on a version untestet by module developer. To avoid lots of confusing bugreports that comes from untested versions i would further stick with setting max version.

[ebon otter]

Sure, as long as you're okay with the fact that the moment you step away from actively monitoring new core releases, your module becomes completely unavailable to users even if it would (probably) work just fine.

[digital drum]

More modules worked in v11 without changes than modules which required changes.

Of the majority set that work fine, the ones which declare v10 maximum are unusable,

I respect each developer’s ability to make this choice themselves. We just recommend no maximum. We support either path

[weary sigil]

also valid, i will follow your recommendation for the slim modules. I am unsure about the (probably) part as even tiny changes like Texteditor.enrichHTML had become async can break a module and even reading the update notes carefully would not have hinted to this.

[digital drum]

Sure, there will certainly be some breaking changes. But the number of modules which, for example, calls TextEditor.enrichHTML synchronously is small

Of course, if these modules already know that they WILL break in v12 due to our communicated deprecation period, this is a great reason to go ahead and declare a maximum!

[brisk valley]

Any guidance on this when dealing with core translation modules? Naturally they do have a maximum core version as new text is added which is not translated by the module.

[ebon otter]

Ehhh I don’t think that really calls for adding a maximum, does it? Module will still work fine with all the other strings.

[night agate]

I don't see why they would have a maximum. If there's a new translation string, it'll cleanly fall back to the default. That's not a reason to prevent the people from installing the translation module and using it for the strings it does have

[brisk valley]

What would be the correct way of labeling the versioning on translation modules then to encourage people to update to the appropriate module version? Leave the maximum empty but bump the min version to the FVTT version the translation is actually for?

[night agate]

Potentially. Or just increasing the module version and calling it a day. The module having unused translation strings won't hurt anything either. Just having a new release of the module with a new version number should be fine when you're just adding new strings

[brisk valley]

Unfortunately my module.json files already have the maximum's set. My understanding is that people installing the module from the in-game installer will be served the data from the package admin panel if I only update the maximums there...

[night agate]

The maximum really only makes sense to add if you're deleting translation strings from the module. In which case, personally, I would just make sure to leave them in-place for a bit longer. A few stray strings isn't going to hurt users (not when their client just never uses them) and it lets you dramaticlly widen your support range for any given version (which is good if you ever need to refine the translation on a string)