FileMaker Custom Function versioning

Let say that you build a FileMaker Custom Function (deploying to different files at different times) and later want to either:

  • Fix a bug
  • Extend its functionality

Either would create a different version of the Custom Function (CF) and you would want to make the version string as visible as possible to your eyes and tools.

What is the best way to implement Custom Functions versions?

[-] Renaming a Custom Function has the downside of making your code less portable. If you copy and paste a script (that uses a CF) into a file where the custom function has a different name it will break

[+] A better way might be to use an extra Custom Functions parameter to store the version and any other text that might be useful when deploy a custom function into your code.

For example a Custom Function signature like...

convertFromFileMakerPath.pre19 ( a_path ; a_format ; v1~PosixPath~WinPath~URLPath )

…becomes

convertFromFileMakerPath.pre19 ( "file:/" & $filePath ; "PosixPath" ; "v1” )

Tested as working and useful when programming in English.

Thoughts?

Can you share some other examples but about the changes introduced?

If a developer introduces a "breaking change" to a custom function, I think the original function should not be altered, rather creating a new function could be a better choice.

If the changes introduced are not "breaking" by nature, then I'm not sure why the versioning needs to be visible outside the custom function code itself.

Can you elaborate on that?

I guess a follow-up question is if someone would embed versioning into a script name?

I see no need to embed versioning in custom function (CF) names or parameters. I can't see how it serves users of the CFs. As @Bobino says, a new CF makes more sense where a change is implemented that either changes a parameter or the result. This has the merit of maintaining backwards compatibility.

As for CF maintenance… comments in the CF code seem more appropriate. You could improve tool visibility by creating a search ID, the concatenation of CF name and version (removing problematic characters along the way). That's as far as I would go.

Normally I do not show version numbers in a CF name. But recently I recreated an older CF that was used in conjunction with the cf CustomList by Anges Barough. In the new version I used the while function instead of CustomList.

In this case I added a "_v2" to the name of the new function. The new function cannot be used with FMP clients pre 17. So both CFs have their place to be.

For the Custom Function...

convertFromFileMakerPath.pre19 ( a_path ; a_format ; v1~PosixPath~WinPath~URLPath )

...imagine that you implemented "PosixPath" and "WinPath" but not "URLPath" in v1, and then later added "URLPath".

That would be a non-breaking change to extend functionality.

Do I understand this correctly? You write the third parameter only for information? It has no other function? I would do it like this - if I have understood your example correctly:

convertFromFileMakerPath.pre19 ( a_path ; a_format_Posix~Win~URL )

Would that not be sufficient? Or did I misunderstand something? It is not important to know that the function was extended. But it is important to know what type of information it accepts.

[Edit:] I find a functionless parameter only for info purposes rather confusing for other developers that get the cf from e. g. briandunning.com or other sources.

Personally, I keep versions information, along with descriptive information, as Comment lines at the head of the function itself. This way the function name stays the same, thus not breaking if redeployed as a newer version, but you can also see in the function content which version is actually in use.

1 Like

In order to avoid any interference with functional elements of the CF, I would only put version information in a comment line within the CF.

you mean pre-18 or <18 or ≤17 //while was introduced in fm18

1 Like

@FileKraft Thank you for your advice. I would have been better off not relying on my memory.

1 Like