With newer versions of MATLAB newer features have been introduced such as the string class that allows creating string arrays and the possibility to define strings using double quotes "" (see answer), among other features.
This is great news because this kind of features make life easier. However, this also brings a problem to the table.
I share code with colleagues frequently and they may not necessarily have the latest version of MATLAB installed. If they run my code written using the newer syntax it will crash in their machines.
What techniques/measures can I put in practice to ensure maximum compatibility/portability of my code?
This post suggests refraining from using the newer features, but then what's in it for me by using the newest version if I have to force myself to use the older syntax?
Is using the older syntax and checking for the MATLAB version the only options I have?
I would do the following:
Decide what versions of MATLAB you want to support. This could be either a specific version of MATLAB (the one you use to develop the code), or it could be a range of versions. This may have an upper bound as well as a lower bound.
Your decision here might be based on the range of versions that you know your colleagues require you to support; or it might be based on practical considerations. For example, I doubt you'd want to support really old versions of MATLAB like v5, otherwise you wouldn't be able to use logical variables, cell arrays, or arrays with dimension greater than two. Or you might really want to use the new string arrays, in which case you'll restrict it to R2017a and above, and your colleagues will have to upgrade.
In terms of recent versions, the really big boundaries are R2008a (which introduced the new object-oriented code) and R2014b (which introduced Handle Graphics 2). But your specific needs may dictate other boundaries too.
Right at the start of your code, test the version of MATLAB using ver or verLessThan, and error if it's not in that range, with a message like 'Unsupported MATLAB version'.
Within that version range, you can either limit yourself to the lowest-common denominator of functionality that is present across all versions, or you can occasionally use a test on ver or verLessThan to switch between behaviours depending on the version.
At the end of the day, if you're producing a product for others (rather than code to be used by just yourself), you need to do some research on what platforms your potential customers have (or can be persuaded to install), find a range of platforms that is big enough to satisfy most of your customers but small enough to be practical for you, and support those platforms.