DB.getVersion() call

[HoloGnome]

MW/Trenloe - Where is the concise list of links to the available rulesets - I'd be happy to start taking a look at the impact as a side project. Admittedly, I do not understand the resistance to fixing basic quality issues, either technically, practically, or idealogically. Maybe I will understand once I start looking deeper, but not likely.

Trenloe - It's not minor functionality when you can't update your own app because there's no way to check the related capabilities change. It's a significant quality issue. Also, at some point, everyone has to update and it's usually not a big deal. I understand that FG has been around for a while, but you should be trying to minimize consequences of basic/previous oversights in the implementation.

For that matter, if legacy issues are a huge concern, then implement a new method called getFullVersion() or add a version call to a different class that does the right thing and there will be no problem, since nobody's using it except new plugins that know about it (but the right solution is to make the existing version call return the full version). Or, add a new Capabilities class and put in methods to return what FG APIs are supported, what graphics engine, what lua version, what full app version, etc. That change would actually be a step in the right direction towards something like Unity or other integrations/changes. It's not much code and would be very useful. Take your pick. No legacy users/issues for the new class.

Also, if developers are keeping rulesets to themselves or there are homebrew ones out there, then the owners can easily fix any issues relating to versions - prob. not more than 1 line of code. And, even if something does get broken, it's not like you're releasing OTP ROMs. It probably won't stay broken longer than a few days and you can be responsive to those kinds of changes/bugs in an era of digital deployment with built-in upgrade checking. With up-front checking for the primary rulesets, you can minimize issues.

Anyway - happy to help as time permits.

[Trenloe]

Trenloe - It's not minor functionality when you can't update your own app because there's no way to check the related capabilities change. It's a significant quality issue.

I'm guessing you don't know how current versions and compatibility works within Fantasy Grounds? Refer to this page: https://www.fantasygrounds.com/refdoc/

Depending on which version is specified in the ruleset base.xml file FG will automatically use the right version compatibility for that ruleset. This is what M_W was referring to when he said he was waiting until 3.1 to make the change for setLighting so he could provide backwards compatibility via this ruleset compatibility version.

With this functionality you have proper product updates and backwards compatibility covered with major.minor release numbers. Hence why I think adding the patch number to the getVersion command is minor functionality which would, quite frankly, probably create more issues than it is worth if ruleset/extension developers are trying to cover update coding themselves when they should be using the built in compatibility functionality.

[HoloGnome]

OK - thanks. If that's the case, then maybe the right solution is to remove the patch level from the main application version and stick with 2-digit versions rather than use a versioning scheme which is different from that supported by the underlying game/ruleset engine. But, why would implementing an internal, non-DB version call, whether as part of a Capabilities class or a stand-alone method, that returns the full application version including patch level have any bearing on ruleset compatibility? The engine would be calling anything in a new Capabilities class, but could eventually migrate to use it when the time was right.

If I understand correctly (maybe not ?) it seems like you're also saying that there will never be functional changes or bug fixes that occur as patch releases that extensions might need to know about, but that doesn't seem to be the case. As we are discussing, if the granularity is at minor versions, then there is no way for an extension to respond to patch changes, where there are long time periods between minor releases (3.0 was about 6 months ago and 3.1 will be ? ). Also, it's not the responsibility of the app to try to account for everything that extensions might do, but rather just provide the api, bug fixes, improvements and supporting information so that extensions can decide what to do and/or parse the environment.

Probably best to pick a way to do the versioning and be consistent across the entire product. Either use patch versions in the engine, either directly or as part of a new Capabilities class, or get rid of them at the application level and just go with Major.minor.

ps. Maybe implied, but my thinking has shifted in favor of a capabilities class because of the fact that FG provides a plugin environment and architecturally speaking, it would be helpful to centralize environment detection/queries in a single class. Also, congrats on the 3.0.4 release, which I will officially call 3.1-