On Fri, May 22, 2015 at 18:50:28 +0100, Carnë Draug wrote:
Yes, that is one of the alternatives. When I found this problem the first
time I started by removing @inputParser from the package. There is even one
in the release packages forum. But because of the points above (and
considering the other thread where I suggest dropping the general package),
I think we would be better off reinstating the @inputParser and releasing it
with depends (octave < 4.0.0).
Your original point about this being confusing is fair and wanting to
clear things up for users by having one definition makes sense.
I would like to keep the signal package as backwards-compatible as is
reasonably feasible. It currently depends on octave >= 3.8.0 and general
for inputParser, it will work with either definition of the class.
Let's assume for now I don't want to change those dependencies.
For this situation which alternative would be better? If a new general
is released that depends on octave < 4, would users of signal be forced
to download an older version of general? Would "pkg load signal" fail if
the new general package is installed? Or would Octave simply not load
the new general package and everything would still work?
If a new package is released without inputParser, then signal would
still depend on it, needlessly, but it wouldn't provide inputParser, and
everything would definitely still work fine.
I'm unsure how the "octave < 4.0.0" case will work, so I prefer the
release with inputParser removed because I am more certain it will do
what I want.