Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> Just to make sure: I did not intend to insult anyone (and in hindsight I
> wish that I had made that clearer).
It is OK that you are wiser in hindsight. We all are, and we try to
do better the next time ;-)
Thanks for reminding of the topic.
As a general principle, when introducing a new feature that achieves
the same goal in a new and improved way, it is safer to introduce it
in such a way that users of older implementations that lack the
feature cannot choose it by mistake.
One way to do so is to we reuse the same configuration knob by
adding a new settings value that older implementations would choke
on, the users will be forced to ensure that the older and proven way
is used consistently everywhere, until every tool the user uses are
ready.
For this instance, I think it is OK to split and allow two to
operate on the same data at the same time, because I believe that
both old and new implementation will leave a permanent difference to
the on-disk data that cannot later be reused by the other [*].
But it is an exception than a norm when adding a new thing that
extends an existing feature (as opposed to inventing totally a new
thing that won't overlap with any existing one). As a general
principle, it is much safer to make sure it breaks (and have users
hold off) when the new setting is given to an old implementation.
* Side note. For example, if we introduce the index-v5 feature
by not reusing the index.version but with index.usev5 variable,
new implementations that know about the knob would write out v5
data that existing implementations will not work with.
Also, from the point of view of the longer-term maintenance, of
course not having to deal with orthogonal looking different
configuration variables where newer ones override the older ones
will induce more pain over time.
