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:

1. Fantasy Grounds has been around for 9 years.
2. Many, many people have created custom rulesets and extensions.
3. 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.