Steve on Image ProcessingOctober 7th, 2009Release notes for old versionsLast week Oliver asked for the release in which CMYK TIFF support was added to imwrite. Oliver then followed up asking for MathWorks to make release notes available for old versions. In case anyone else is interested, here's one way to navigate to release notes for older versions of MATLAB.
Note that release notes are available there for releases back to R14 in 2004. The release notes summarize new features, compatibility considerations, and fixed and known bugs. Similarly, you can find release notes for the Image Processing Toolbox going back to version 2.2.2 in 2000. We aren't always perfect about remembering to include everything in the release notes, but this is something we're trying to get better at. To answer Oliver's original question: Since MATLAB 6.5.1 (R13 SP1 in 2003), imwrite has written a CMYK TIFF when passed an M-by-N-by-4 input array. 17 Responses to “Release notes for old versions” |
|
|||
|
These postings are the author's and don't necessarily represent the opinions of The MathWorks. |
By the way, it would be nice if the documentation of each Matlab function could include a “birth date”, i.e. the Matlab version number at which a given function has been introduced.
Frederic—Thanks for the suggestion. I’ll pass it along.
I made the same request for enhancement Frederic suggested, at least a year or more ago. I hope more people make the same suggestion because I often need to know how far back a function I write will be compatible. Just a little note at the end of the help, i.e.,
Matt (and Frederic)—Y’all are not alone, and I really will pass this along to the right people.
If I look at any function in my current version of Matlab, I can see the revision number for that function. However, it would be much more helpful if I could go somewhere, either in the help or on the Mathworks website, and see a list of functions and the revision number included in each release of Matlab. Release notes rarely include minor bug fixes and updates to functions, only the major changes. A table of release numbers would allow me to look at any function and see both when it was introduced and when both minor and major changes occurred to it, even if it didn’t give me any details of what those changes were.
I requested this once as a followup to a troubleshooting request, and was simply told that the Mathworks policy was to document major changes in release notes, and that they didn’t have a history available for minor changes. However, I assume the Mathworks keeps copies of all previous releases, and it would be pretty simple to parse the revision number out of all functions (I’ve done it for the two versions I have available to me, R2007a and b). Any chance of this happening?
Kelly—I believe it is very unlikely.
Steve,
Can you elaborate? I’m not asking for a list of all the actual changes made to functions, just a list of which version shipped with each release. Not a difficult, time-consuming, or costly suggestion… why is it so unlikely?
Kelly—Because I believe that it would difficult, time-consuming, and costly. And, in many cases, the data would be misleading for users, resulting in confusion and higher support costs.
Kelly,
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?
Kelly-
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
Thanks, Steve. My google search didn’t turn up the old release notes, so it’s good to know where to look now. Fingers crossed for an “available since” on functions at some point. Of course, there are ever increasing levels of detail you could go to (e.g. when a particular feature of a function was introduced), but I appreciate it’s a case of diminishing returns for TMW.
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.
Oliver—I’m glad I could help. I’m not completely certain, but I think the “missing” doc about CMYK output was one of those cases where we documented the change in one place (M-file help) but not the other (reference page), or vice versa. Duplication is a generic evil in software, and we’re looking at ways to improve our handling of the doc.
I also strongly support the idea.
I have just recently bumped into the problem that im2single was not included in an older release of the image processing toolbox. I have spent about an hour trying to locate it at the release notes page, with no luck. Does anyone have a clue when it was introduced? I would really appreciate any help.
Kristof—Single-precision arithmetic was added to MATLAB 7.0 (R14), and im2single was added to Image Processing Toolbox at the same time.
Just adding my voice: this would be very useful. I haven’t been able to find just the documentation for older releases anywhere on the mathworks site. Making this available would be a simple first step. Putting notes into function documentation to indicate when the function became available is helpful too, although doesn’t capture potential changes to the function’s input/output formats.
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.
Peter—Thanks for the suggestion. I forwarded it along.
I knew I couldn’t be the only one interested in a change history. :)
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/).