DB.getVersion() call

[HoloGnome]

I was playing around with the DB.getVersion() call and was hoping that it would return the full version to the client, but it doesn't. Then, I looked at db.xml and saw that the db wasn't actually storing the full client version, just major.minor (and not patch). In other words, 3.0 instead of 3.0.3.

Is it possible to extend this functionality so that it returns the full client version, meaning MAJOR | MINOR | PATCH? Or, add a call somewhere that will return the full application version?

There may be changes that occur at the patch level that scripts want to check for, especially since there is an extended release cycle, and it would be nice if it worked.

On a positive note, I liked the fact that DB.getVersion() (no params) did what made sense and passed back major.minor.

[Trenloe]

Use DB.getRulesetVersion to return the "release" information of the ruleset. You may need to parse the tables returned for layered rulesets.

[Moon Wizard]

The minor version isn't saved in the db.xml files currently, so there is no data to get.

What patch level changes are you trying to capture?

Regards,
JPG

[HoloGnome]

The minor version does appear to be saved in the DB, but not the patch level. For example: version="3.0". Major = 3, Minor = 0

Trenloe: I see the release info for the ruleset and that is helpful, but I am still interested in the app version where where major changes would occur at the API level vs. the rulesets.

As above, I was expecting to get back the full application version. From a design and utility standpoint, it's a good idea to return the full version from a getVersion() call.

For example, if there is a fix for the setLighting ABGR-ARGB issue in a patch version, it's not detectable. It's just good practice. Or, let's say you were to implement a very useful Interface.getLighting() call in a patch so that extensions could detect the current lighting before modifying it so that it could be restored. Currently, the only option is to script error out.

Whether or not these things will transpire is uncertain, but that doesn't obviate the need for best practices to support the case where extensions or other active script modules do actually check for patches so that they can be well-behaved or take advantage of changes.

I guess the bottom line is: is it possible to provide a complete application version string with the getVersion method or some other basic method?

[Moon Wizard]

That's why I didn't provide the fix for setLighting parameter yet, waiting for 3.1 to rev for exactly that reason. For backward compatibility reasons, I don't think it makes sense to change getVersion at this point.

Cheers,
JPG

[HoloGnome]

When you can't apply fixes to an application because it doesn't display a full/proper version number, it's a pointer to reconsidering the versioning scheme to follow software engineering best practices. I realize you have a lot on your plate. But, if adding a patch version on a getVersion() call and/or in the db so that your application can return/use its full version breaks anything, it can't be more than a 1-line change of whatever happened to be affected - ruleset, etc. - that would easily appear in the first moments of beta testing any new build. It's a basic and important quality step. the bigger impact is probably in not doing it and holding up other quality improvements. The sooner the better, IMO. And again, just trying to be helpful in case that doesn't come through in faceless communication.

[Trenloe]

But, if adding a patch version on a getVersion() call and/or in the db so that your application can return/use its full version breaks anything, it can't be more than a 1-line change of whatever happened to be affected - ruleset, etc. - that would easily appear in the first moments of beta testing any new build.
And what happens to all of the custom rulesets and extensions out there that might get broken? This might not turn up for a long time in testing as it would only appear when the specific code is being used and who would be expected to change that code that has been broken?

Allowing the possibility of breaking long standing code is definitely not following "software engineering best practices".

[HoloGnome]

Hi Trenloe - It's your call, and I would beg to differ, respectfully/technically. Any issues relating to ruleset version-checking compatibility could be easily checked in an organized manner and/or with a modicum of community beta support (perhaps including ruleset creators). It's a bounded problem - there aren't that many rulesets to check.

The strawman you present for not addressing quality issues doesn't hold up for me. You guys know what rulesets are used primarily with FG and have access to the code, since they're all text/zip files. You could easily (and quickly) search to see how (or if) getVersion() is being used and where problems might arise, rather than just waiting around blindly for some problem to happen down the road in a black-box execution context. Also, and in the nicest most good-natured tone (really just trying to help), there's no excuse for an application not being able to return a correct version string to support basic information, capability checking, or patch-checking, as needed. Best practices are what go into the application first, rather than what you invoke as a spectre to perpetuate problems in the codebase. Again - just trying to help and intend these comments in a very positive context. I hope that's OK.

[Moon Wizard]

The problem is that there are 20+ rulesets each written by different people and at least twice as many extensions. There are also rulesets and extensions that I don't have access to, but that I've heard about. (Mainly foreign language and house rules) In general, when dealing with user-generated content, you can't assume anything.

Even if I could assure that we have access to every piece of user-generated code, we don't have the manpower to review and update all those pieces.

Cheers,
JPG

[Trenloe]

You could easily (and quickly) search to see how (or if) getVersion() is being used and where problems might arise, rather than just waiting around blindly for some problem to happen down the road in a black-box execution context.
I think you're missing some very important background information here:

Fantasy Grounds has been around for 9 years.
Many, many people have created custom rulesets and extensions.
Some of these custom rulesets and extensions are not available on this website - with the developers publishing them elsewhere or just keeping them to themselves.

Thus, your suggestion that "someone" (I'm not sure who you mean by "you") can "easily (and quickly)" check for where getVersion is being used is simply untenable.

Please remember that this is a product that has been used, and cutomised, by thousands of users for close to 10 years. "Backwards Compatibility" should be the mantra here and that shouldn't be ignored just because you feel that a very minor piece of functionality (yes, it is a very minor piece of functionality) should be added.

EDIT: Moon_Wizard got there before me, but we're essentially saying the same thing. :)

[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- :D