search

Moerill / fvtt-pointer

MIT License
6 stars 16 forks source link

[BUG] compatibleCoreVersion=0.8.9 #20

Closed ScottMaclure closed 3 years ago

ScottMaclure commented 3 years ago

Describe the bug

Current mainline release version is version 0.7.9.

https://github.com/Moerill/fvtt-pointer/blob/master/module.json#L25

"compatibleCoreVersion": "0.8.9",
"minimumCoreVersion": "0.8.1",

Should be 0.7.x?

image

ScottMaclure commented 3 years ago

Raised PR: https://github.com/Moerill/fvtt-pointer/pull/23

Moerill commented 3 years ago

No this is correct.
The new version is for the 0.8.x branch.
While i know that one is not supposed to use compatibleCoreVersionwith future versions that do not exist, i do not want to update this each patch. Also i'm pretty sure that this one won't break. (at least after the next alpha 0.8.2, since i ts mostly independent of FVTT inner workings)
So the result would be either me updating every minor foundry update or users having compatibility warnings. Since both are annoying i chose to do it like this for modules where i'm very very sure that they won't break in bugfix updates.

ScottMaclure commented 3 years ago

Hrm, I feel like this feature of FoundryVTT is a weakness. Does Foundry follow semver I wonder? It would be nice if they did, then the major version increment could indicate breaking backwards-compatibility.

Q) What happens if you need to make a bugfix before 0.8.x clients are released? I wonder how the "Blocked" state in my FoundryVTT client (as per screenshot in OT) works?

Regardless, thanks for providing this module. Am going to use it for my first FoundryVTT game as GM. Kudos.

Moerill commented 3 years ago

Hrm, I feel like this feature of FoundryVTT is a weakness

Its a bless and the most annoying thing. Main reason is to easily identify not maintained modules that shouldn't work anymore. But for the mass of decently active maintained modules its to annoying (at least for me) to just update that flag every time a foundry update comes..

Does Foundry follow semver I wonder?

Nope. Its a frequently discussed topic and it doesn't. Generally: 0.x -> 0.y does provide breaking changes to some areas. 0.x.0 to 0.x.2 are alphas including breaking changes from version to version. (so these would be your "major version changes". But i've a few modules that are just not affected by foundry stuff for quite a few big version changes) The new goal now is to have less breaking changes going from alpha to beta to stable.. Which didn#t work once, but the foundry staff is heavily at work to make it better and nicer here for the module/system developers. In general they're heavily working with module devs (partially with the league of foundry fvtt developers as middleperson) to make this easier and break less stuff.

Q) What happens if you need to make a bugfix before 0.8.x clients are released?

then i either need to push a regular update, with lower compatibleCoreVersion flag, or decide to just not do it (which is what i'm doing. Cause i only focus on one foundry version. Not really enough time for more stuff.)

I wonder how the "Blocked" state in my FoundryVTT client (as per screenshot in OT) works?

In theory you shouldn't be able to update to the 0.8.x version from within foundry, when you're not on 0.8.x. If that is happening, its a core bug afaik. So that state shouldn't really happen in "regular use"