[Xapian-discuss] Deprecation policy question

James Aylett james-xapian at tartarus.org
Mon Sep 24 12:58:31 BST 2007


On Mon, Sep 24, 2007 at 12:44:26PM +0100, Richard Boulton 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.)

I guess my only question is: why are we calling this 1.0.x not 1.1.x?
In my mind, the only thing that really gets fixed about version
schemes is the major; minor granularity is determined by the project
in question, and for a library the ability to compile across a minor
version feels sensible.

I'm +0.5 on this concept at most though, so if others disagree that's
fine. Either way I'm still in favour of strategy (1) for deprecation
macros.

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

Yeah, that's so minor I think it's fine to break the rules. (Can the
macro text say precisely the simple step needed to fix things in this
case?)

J

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james at tartarus.org                               uncertaintydivision.org



More information about the Xapian-discuss mailing list