JADE Environment Development Ideas

What's new in the upcoming JADE release?

IMPROVED DEVELOPER EFFICIENCY. ENHANCED SECURITY. SMOOTHER INTEGRATION

The JADE 2022 release meets tomorrow’s business demands.


Start your update to JADE's latest release

Provide ability to determine version information for .bin files

With the JADECare deployment methodology having to cater for features which start in a specific hot fix and the hot fix being released in the system files (.bin) it is an urgent requirement that we are able to programatically access the version information for a set of system files. This will allow us to identify whether a hotfix is in-place or not.

 

We can easily identify a hotfix where an exe or dll is part of the hotfix by using the product version property but this is not available for JADE's system files.

 

This was earlier requested in NFS 52755 but we have user-cases now that require this ability (ie hot fix 18.0.01.049)

  • Martin Jagers
  • Nov 21 2019
  • Future consideration
  • Attach files
  • Martin Jagers commented
    November 21, 2019 20:38

    Am I correct in assuming that when bin files are released in a hot fix, they are always released as a full set?

  • Martin Jagers commented
    November 21, 2019 20:37

    Yes, we could parse the versioninfo.txt but what a painful way of doing this.

     

    And the feature I'm looking for is to be able to look at this file externally when it is not a part of my set of database files.

    Examples:

    1. the JADECare Systems Manager (JSM) holds a raft of files for each JADE release and all hotfixes and each of the bin files is external to the JSM database.
    2. JADECare Systems Agent (JSA) may be running on JADE 2018 and the environment its managing is running on a different set of binaries that may be earlier or later than what JSA is running. JSA needs to be able to identify what hotfix is running for the bin files.

    So please review this JEDI from the point of view of looking at the bin files as external files. In the second example we could run an application that returns the required information but that doesn't satisfy the first example and why the DbFile::getPatchVersion is not appropriate.

  • Ty Baen-Price commented
    November 21, 2019 20:24

    You know you could always have done this by parsing a versioninfo.txt. Also, only bother doing getPatchVersion for _system: the others will always be the same as _system.

  • Martin Jagers commented
    November 21, 2019 19:56

    Just noted that there is a method on DbFile class called 'getPatchVersion'. So by checking all files with kind of System (DbFile.Kind_System) we can get this information already.

    Please close this JEDI.