In my case, I often tweak, optimize, or rewrite parts of code I’ve downloaded from the file exchange or in a third-party toolbox. Sometimes it’s just a matter of taking advantage of more recent syntax, whether it’s for a performance gain or simply my (and often MLint’s) style preference. :-p I have yet to submit any as patches, though, because I know it’s quite possible that it was an intentional compatibility measure that I just undid. It would be great if a change history of at least just the syntax of the language could be put together.

I would think that would be pretty easy since changes to keywords, operators, etc. are infrequent, typically of a pretty simple nature (introduction or addition of a new usage), and perhaps even individually memorable to Mathworks developers. (I have a mental image of an intern being handed a clipboard, syntax cheat-sheet, and pencil at the next company picnic. :-D)

As an ultimate goal I think the approach Peter described would be ideal. It would provide maximal detail (short of patch files) and require far less work to compile and maintain than would explicit change histories, I would think. Function help for past releases is already online–access is just limited. The least ambitious attempt (tracking not functionality, but functions, per se) could be nearly entirely automated while still providing some value to users. Continuity through more complex changes (e.g. a function is renamed, splits and merges of functionality between functions, etc) could be tackled incrementally. In the meantime, users could at least get a conservative sense of the cut-offs to use in their verLessThan checks (http://blogs.mathworks.com/loren/2007/11/14/what-version-is-being-used/).

Ultimately an approach like you see on apidock.com would be great. For each function doc page you have a list of all releases that included the function and can click to see the documentation from each version. This is not so difficult to compile once you have the text of the documentation for each release available.

Thanks for the tip on cmyk support, too. I was able to add cmyk tiff output to export_fig without any version checking as a result.

Sometimes the only change is a date or version information or information for the See Also line. But the revision number would still change. This can add to the noise rather than the signal.

I am still very sympathetic for wanting to know when functions were introduced or significant changes made.

–loren

If we told you that version 1.2.3.4 of function foo.m shipped with R2011c and version 1.4.3.2 of that function shipped with R2011d, how would you use that information? What types of changes would you expect to have been done to that function between R2011c and R2011d?