Download older versions of a file in File Exchange?

Is it possible to download older versions of a file in File Exchange? If yes, how? If no, do you know why?

The case is simple, when you refer to a file in file exchange, you refer to its API at the time of referral, but the author can change the API and your reference will be invalid. It doesn't seem like a good practice to keep a copy of the file and refer to that instead of the page on FEX.

Answer 1

[Cedric]

It is not good practice, but if you are stuck with no time to update function calls in 100's of m-files because of a small change in the interface (.e.g different order in input/output parameters, or use of an inputParser with named parameters in the new version), you can build a wrapper for the new version of this function which has the interface of the old one.

Example: if you were using the outstanding, but outdated function doSomething

 function [z, msg] = doSomething(x, y)
    % Some code.
 end

and its author decides suddenly to use an inputParser and reverse output parameters (shame on him)..

 function [msg, z] = doSomething(varargin)
    % Some code.
 end

so calls to the new version should be done as follows:

 [m, z] = doSomething('yValue', y, 'xValue', x) ;

(you know, named parameters, as e.g. in calls to PLOT with optional args.)

Well, a temporary solution for not having to update all calls immediately would be to rename the new version into doSomething_NEW:

 function [msg, z] = doSomething_NEW(varargin)
    % Some code.
 end

and to write the following wrapper, which has the same interface as the old version:

 function [z, msg] = doSomething(x, y)
    % Wrapper for DOSOMETHING_NEW
    %   This is a **temporary** solution because I don't have
    % time to update calls everywhere now.
    [msg, z] = doSomething_NEW('yValue', y, 'xValue', x) ;
 end

But.. be sure that if people could down-vote solutions involving bad practice, this solution would hit -8000 ;-)

[Jan]

A wrapper for a function downloaded from the FEX is not bad. Relying on specific details of the code of a foreign programmer is fragile and a wrapper helps to use well tested original software with a personally adjusted interface.

Wrappers are ugly for builtin function like masking the new style of teh set functions like unique: While modern Matlab versions can simulate the old behavior by unique(x, 'legacy'), old versions fail due to not recognizing the 2nd input. This means that code using unique cannot be written forward and backward compatible anymore without a wrapper, which considers the Matlab version. And this is an increase of the complexity level without any benefit and in my eyes a really bad decision of TMW.

Therefore I upvoted this suggestion.

[Cedric]

I agree with your arguments Jan, yet, here are the reasons that motivated my warnings..

• It is rare that we have objectively no time to update function calls, and the driving force for writing a wrapper can easily be lack of motivation.
• It is rare that an author (especially for serious FEX entries) just changes the order of the arguments. Usually authors have good reasons for adding/removing arguments, and the wrapper is just a technical way to discard these reasons.
• Unless wrappers leave a warning somewhere, we tend to forget them, which can lead to "forests of wrappers" in large projects.

[Jan]

I've accepted this answer.

[Cedric]

Thank you Jan!

[Jan]

Thank you, Cedric! :-)

Answer 2

[Jan]

You can simply contact the author and ask for an old version.

Usually authors have good reasons for changing the input and output arguments. Then keeping a variety of different version will confuse many users.