Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Do not upgrade to Matlab2009a
Date: Thu, 16 Apr 2009 00:29:02 +0000 (UTC)
Organization: Universit&#228;t Heidelberg
Lines: 17
Message-ID: <gs5u4e$77o$1@fred.mathworks.com>
References: <gs027a$8d1$1@fred.mathworks.com> <a8593395-478c-4c7c-8011-d8a999911cdc@y10g2000prc.googlegroups.com> <gs4gst$pn3$1@fred.mathworks.com>
Reply-To: <HIDDEN>
NNTP-Posting-Host: webapp-05-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1239841742 7416 172.30.248.35 (16 Apr 2009 00:29:02 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Thu, 16 Apr 2009 00:29:02 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 869888
Xref: news.mathworks.com comp.soft-sys.matlab:533071


Dear Scott!

I am surprised by the emotions in this discussion. The facts are simple:
1. Upgrade means: new features, new bugs, some fixed old bugs, some incompatibilities.
2. No upgrade means: no new features, no new bugs, no fixed bugs, no incompatibilities.
This is the classical behaviour of complex systems and not restricted to powerful software. As consequence the decision depends on the demands of the user: If you need new features, buy a new release and be frightened of new bugs. If you need a reliable system with known limitations/bugs, stay at the running and tested release.

Users can control (not avoid!) problems in current versions by participating in this newsgroup and reading the release notes on the Mathworks web pages. Unfortunately, these web pages are not complete, e.g. I was not able to find the information, in which release FOPEN stopped supporting files in VAX-D format, because the function reference can be explored for the current Matlab release only (am I right?). After I moaned in this newgroup, a friendly employee of Mathworks contacted me and offered to convert my files! Although this was impossible, because it concerned 50.000 files containing clinical measurements of patients, I was absolutely satisfied with the service. It took me 2 weeks to figuring out the problem and writing a conversion tool.

Scott wrote:
> ...The reason I ask is that when assessing a proposal to make an incompatible change we look at the anticipated impact on our users, but we are guessing as to what various users' tolerances are for dealing with changes.  If a change has seemingly easy/low-cost/acceptable workarounds, we are certainly more likely to consider it.

Remaining questions:
By which method do you estimate the complexity/cost/acceptance of workarounds for incompatible changes? How does Mathworks get feedback before an incompatible change is inserted in a published release?
Do you think, the list of open bugs (http://www.mathworks.com/support/bugreports/) will get longer or shorter in 2009?

Kind regards, Jan