#1173 Issue closed: RFC: How to get rid of "disgraced" functionality?¶
Labels: documentation, cleanup, discuss / RFC,
no-issue-activity
jsmeix opened issue at 2017-01-19 09:47:¶
I request for comments what the right process is
how to get rid of disgraced functionality in ReaR.
Over the years lots of functionality gets added to ReaR.
Most of it turns out to be actually useful in practice.
But some functionality turns out to become more and more
a hindrance or it even turns out to be "simply wrong".
I would like to get rid of such "disgraced" functionality in ReaR
in a reasonable way so that the resulting backward incompatible
changes do not hit the users out of a sudden.
My ad hoc idea is to declare functionality "deprecated"
in one version of ReaR with a planned timeline in what
future version this functionality will be finally dropped
plus
LogPrint messages if that functionality is actually used that
inform the user about "deprecated and planned end of life".
gdha commented at 2017-01-19 14:49:¶
@jsmeix please define what you mean with disgraced functionality? Can you give an example?
jsmeix commented at 2017-01-19 16:32:¶
With "disgraced functionality" I mean functionality
that we do no longer like to have in ReaR.
The "we" therein means there must be agreement
before a functionality can be dropped.
My current examples where I personally think
it would be better if that functionality was not in ReaR are:
MANUAL_INCLUDE cf.
https://github.com/rear/rear/issues/1019
USB_RETAIN_BACKUP_NR cf.
https://github.com/rear/rear/issues/1166#issuecomment-273101775
and related to that I also think its reverse-logical counterpart
NETFS_KEEP_OLD_BACKUP_COPY
is questionable because currently ReaR behaves contradicting
with backup on USB versus on NFS.
In particular I think for BACKUP=NETFS ReaR should behave
same for all BACKUP_URL that are supported for NETFS.
In general I think ReaR should not implement
any kind of backup management functionality.
UDEV_WORKFLOW cf.
https://github.com/rear/rear/issues/840
Bottom line from my point of view:
Some special "corner case" functionality does not work well
and it could be a horrible effort to make it work well and
probably it is impossible to make it work well without some
incompatible changes here and there but then I wonder
if it is not better in the end to get rid of such functionality?
jsmeix commented at 2017-09-07 12:28:¶
@schlomo suggested in
https://github.com/rear/rear/pull/1475#issuecomment-327782839
a way how to deal with backward incompatible changes,
i.e. a test with a meaningful Error exit message
that enforces the user to adapt to the new way.
jsmeix commented at 2017-09-11 09:53:¶
According to
https://github.com/rear/rear/pull/1475#issuecomment-327823112
also @gdha likes a test with a meaningful Error exit message
that enforces the user to adapt to the new way.
And I (@jsmeix) also like it this way because I also
"favor the Error message to make the whole topic more explicit
and to get our users to actually update their configuration" cf.
https://github.com/rear/rear/pull/1475#issuecomment-327784670
github-actions commented at 2020-07-02 01:33:¶
Stale issue message
[Export of Github issue for rear/rear.]