[Xapian-discuss] Deprecation policy question

[Richard Boulton]

James Aylett wrote:
> Conversely, it sounds wrong to me to introduce that situation in the
> first place. Do we have an example of a deprecation change introduced
> within a release series that it's impossible to compile smoothly
> across? We should be avoiding those situations strenuously IMHO.

Currently, we're likely to be adding a new form of 
QueryParser::add_prefix() which takes three arguments in 1.0.3 (ie, 
unless Olly decides he really dislikes my change and backs it out). 
This will deprecate both the old two argument form of add_prefix() and 
the add_boolean_prefix() function.

If we add the warning now, it won't be possible to write code which adds 
a prefix to the queryparser such that it compiles without warnings in 
1.0.2 and 1.0.3: if you use the old form, you'll get a warning with 
1.0.3, and if you use the new form, you can't compile with 1.0.2.
(Your points about whether this is a problem or not are perfectly valid, 
though.)

Other than not adding the deprecation warning for the old forms at all 
until 1.1.0, we can't avoid the situation that you can't write code 
which compiles without warnings for a whole release series.  My option 3 
is basically saying: we're going to remove the old form at some point, 
so let's mark it as deprecated in the documentation and deprecation list 
now (to give developers as much time as possible to change their code), 
but let's not cause people to start getting warnings until we move to 
the next release series.

On the other hand, another change we've made is to deprecate 
Enquire::register_match_decider() (which didn't actually do anything). 
Even under option 3, we'll add the warning immediately because any 
Xapian user can simply remove the call to register_match_decider() from 
their code, and compile correctly with 1.0.0 onwards.

-- 
Richard