JSL version change documentationI'm sure we have all encountered customers with this issue... a customer is using JMP 13 and refuses to upgrade to newer versions for JSL compatibility reasons. He says he has thousands of scripts which would need to be updated and it is not clear to him what updates are required. Do we have any documentation/guidance which specifies how to convert a JMP 13 script to 16+? A cursory search turns up nothing.
Re: JSL version change documentationJMP Development has the same issue with JMP! New versions of the IDE, compiler, or code libraries, and developer changes to source code can break JMP. We adopted the industry's best unit testing practice a long time ago. We published the JSL unit test framework that we use in-house on the JMP Community a long time ago. We run billions (OK, maybe not that many) of tests every night after the daily build to verify bug fixes and new features and that no regressions have been introduced. This testing is fully automated, or we can run individual tests, too.
Companies that depend on JMP scripts should also adopt this practice. It does not prevent bugs but helps you find them when you develop or modify scripts or upgrade to a new version of JMP.
Developing unit tests is more work. It requires careful thought and design and more development time. We divide the programming and testing effort in JMP Development (another best practice). Still, companies might have only a few JSL programmers so that the same developer might write scripts and unit tests.
Documentatoin is essential. We devote a lot of effort to making it as useful as possible. How would you use an exhaustive list of all the JSL changes across so many versions of JMP? The unit tests would target the changes to the JSL you actually use. It is much more effective and practical.
Re: JSL version change documentationSo after an exhaustive search, the only thing I could find is this: JMP® New Features and Release Notes - JMP User Community
But this documentation does not cover the all the JSL changes which have occurred (ex. column name references in JMP16), nor any best practices on converting JSL 13- scripts to 16+.
It looks like there is a gap in documentation for converting old JSL to new, and it is impacting customer adoption of newer JMP versions.
Re: JSL version change documentationHey! Scripting changes didn’t always show up in those release notes. A more reliable source is the compatibility notes appendix of the scripting guide. That will tell you most of the gotchas between the version the guide is for and the previous version. You’d have to increment through to get everything.
That said, I’ve had a lot of customers in this boat and I generally call their bluff. I remind them they can have two versions on the same machine. I tell them to install the new one along side the old, and run their most critical or complex scripts on the new version and see if they work. If something breaks, we’ll deal with it. But, the funny thing is - nothing ever has. The log might get some “this feature will be removed in future release.” notes, but the script still runs. The devs have done a solid job maintaining forward compatibility in JSL. I’ve used this strategy for scripts authored as far back as v7.
The only issue (of any kind) I’ve run into is ODBC driver to JMP bitness matching. But, that’s not a JSL issue. When that issue does happen, it throws a clear error in the log. But, I think 13 was the first 64bit-only release. So, that shouldn’t be an issue.Re: JSL version change documentationIf customers have so many scripts and programs it is a shame they have not participated the early adopter already. Besides version control and unit testing this is the best way to check if the scripts will still run in the upcoming version (even if the company will not upgrade, for testing purposes a single machine to test against would be enough.
From a compatibility point of view, I expect several issues from JMP 13 to a newer version as soon they use platform elements to gather for values, outlines and similar. As some platforms have changed the style and structure in the past releases this will pop up for sure.
However, I would start guiding them to a best practice for coding. And push them to participate Scripters' Club meetings. On this page you'll find all the recorded sessions within the past 2,5y from the European Scripters' Club. With some guiding and best practices sessions but also with a complete curriculum in 2023. These sessions have been managed and presented by actual users from our customer base who are responsible for training, automation and more in their companies.
Re: JSL version change documentationHere is another excellent resource: https://www.jmp.com/en_us/articles/unit-tests.html
Re: JSL version change documentationYeah, so having two versions of JMP in parallel has been what they have been doing to date. JMP 13 for running scripts and 17 for everything else. With JMP 18, there is a push to get everyone off older versions, and it is causing churn for customers who have been kicking the JSL update can down the road. I would love to hear how customers have gone about this exercise of script updating. The person at NVIDIA who is having this issue claims it is too difficult a task to do this update on his own (creating JMP scripts is his sole job function). So he's looking to me for guidance on how to go about this. The only thing I can think for him to do is hire a JMP partner (Predictum?) to assist. I'm open to any other suggestions if people have best practices they are able to share.
Re: JSL version change documentationI agree with @martindemel & @Mark_Bailey - a gram of prevention is worth a kg of cure (to be a metric snob :nerd_face:, 
). But in your person's case, I'd take a page from the book we use for our validation tool on the quality page. The tool doesn't check all the capabilities of JMP. Rather, it checks edge cases that are known hard problems and tests the performance/accuracy on those. I don't think your customer needs to involve a third party to run every script in the library. I'd advise them to choose their most complex or mission critical scripts - call it the top 20. Run those and check if they fail. If they're good - odds are that everything else is as well.
To help put the spur to them to get moving on this you can also imply (maybe not in writing) that you're not sure how long we'll be able to get keys for the older versions of JMP now that we are a separate entity from SAS. We EOL JMP 16 in a little over a year, so JMP 13 has been buried for a while now.
