RFC: How to get rid of "disgraced" functionality?

[jsmeix]

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]

@jsmeix please define what you mean with disgraced functionality? Can you give an example?

[jsmeix]

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.
#1019

USB_RETAIN_BACKUP_NR cf.
#1166 (comment)
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.
#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]

@schlomo suggested in
#1475 (comment)
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]

According to
#1475 (comment)
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.
#1475 (comment)

[github-actions]

Stale issue message