Re: general package, inputParser, 4.0.0 release

[Carnë Draug]

On 23 May 2015 at 07:48, Julien Bect <address@hidden> wrote:
> Le 23/05/2015 00:50, Mike Miller a écrit :
>>
>> 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.
>
> Another alternative would be to release a new version of the general
> package, where the old @InputParser class is still present but only
> installed if Octave < 4.0.0 is detected at install time (post_install).
>

I dislike this mostly because I don't trust enough pkg() or myself to not
mess up something and accidentally remove users files.  Specially considering
that some users install packages as root.

I ended up releasing it without inputParser at all, and being dependent on
octave 4.0.0.  Even though a new release of signal has been made that no
longer depends on general, Mike's reasoning is valid for any other package
out there.

Carnë