375981_en-US

liliconcom

JSL Compatibility between JMP versions

I have a lot of users that are going from JMP 14 to 16...skipping 15 altogether.

 

I noticed that there are no "JSL Compatibility  Notes" listed for 15 or 16 here: https://www.jmp.com/support/notes/41/004.html .  Is it safe to say there are no known issues that users will face if there are no JSL Compatibility Notes listed for those versions if they go from 14 to 16?

 

Thanks!

Re: JSL Compatibility between JMP versions

Adding to Mark's unit testing comment. If they have critical scripts they also should consider version control systems to track changes they made in the scripts. 

Re: JSL Compatibility between JMP versions

Another thought is that the Scripting Guide for each release has a chapter called "Compatibility Notes."  There's lots of good info in there that doesn't necessarily make it into the New Features documents:

Re: JSL Compatibility between JMP versions

I recommend that they consider adopting unit testing for 'mission critical' scripts. This approach is the only way to build a safety net to catch bugs that are introduced for any number of reasons. There is no general solution. The unit test is the way to verify specific behavior and results in a particular use case.

 

See this introduction to JSL unit testing and the framework developed as an JMP add-in.

Re: JSL Compatibility between JMP versions

Hi Wendy, 

 

I would say something like this (via a call): 

"Though there is no severe compatibility known so far, we recommend to test your scripts with the new version before switching completely. A good practice in the past has been to participate in the early adopter program where you will gain access to the new version in a Beta mode. There you can test your codes way ahead the official shipment and provide feedback to the early adopter team at JMP. If there are issues with compatibility we can incorporate this and either fix or let you know what the new way of programming would be." 

 

Via call, as I then can also check with them how many scripts they do have, if they considered good programming practices as Don and Mark have come up with and what purpose these scripts do have (simply replications of tasks, add-ins, complete scheduled tasks relevant for their daily business, critical applications, ...

 

In my experience at a certain point we really need to guide the users to think about these things, as most often it has grown over time and is actually a mess of scripts all over the place making maintaining a tough time