Closed rlwhitcomb closed 2 years ago
If this is done at the "getFileContents" level in Calc.java then we could use a regex to parse it and do a quick check before sending to the parser.
Right now the bottom-most level of file reading is "readFile" which calls FileUtilities.readFileAsString(). This latter should be replaced with an intermediate routine that reads the file and does the regex check as suggested before returning (or throwing). Maybe need new VersionMismatchException (derived from CalcException) and caught at the "highest" level.
Remember that now, the library.calc
code needs to be updated every time either "version.properties" (for Calc) or "build.properties" is updated.
If there was some process (maybe a predefined function) that would check if the current version is >= the given one, then each library could basically check it's compatibility with a line at the top:
checkversion('2.4.35', '1.5.47')
(where the second is the base library [from build.properties] version) Then as we make possibly breaking changes an older version could refuse to load the library. BUT, this wouldn't work if there were syntactically breaking changes if the whole library needs parsing before running this check, so it would have to be something checked during file reading, probably with a leading line comment or something (like XML headers). More like this as the first line://** version: 2.4.35, base: 1.5.47
which could be left in the file (since it is a comment), or dropped -- wouldn't matterOf course the "standard" library(ies) would need to update their versions as new features are added.
Sometimes (rarely, but it happens) we make slight mods without updating the Calc version, or the base version, relying on a build number change to distinguish, but since these are not "incrementing" in a semantic version sense (just being commit hashes) this would be difficult (impossible essentially?) to do the >= comparison without keeping a sequential list of commits .... Probably just have to be rigorous about updating versions...