[Xapian-discuss] Deprecation policy question

[Richard Boulton]

James Aylett wrote:
> You can add new features in revisions. It's deprecation that I'm
> suggesting should only be introduced at minors. This either means you
> slow down the removal of things (because you have to wait another
> minor cycle), *or* you push through minors faster (because you hit a
> minor every time you start the deprecation cycle for an API call,
> rather than postponing the deprecation cycle for that call to match
> your 'natural' minors cycle).

That's roughly what my option 2 suggests, of course.  Except that in 
option 2 we document the features as deprecated straight away.  We 
could, of course, instead document them as "to be deprecated at next 
minor release" (which might best be done simply by adding a bug report 
for them, and tagging the bug as a blocker for the next minor release). 
  But, if it's just documentation, and not causing compiler warnings or 
anything, it seems silly to make a distinction between "will be 
deprecated" and "is deprecated".

Still voting for option 1?

(I've been going round in circles with my thinking on this, which is why 
I posted to the list.  I'm currently tending towards option #1, for 
reference - making it obvious to users as soon as possible that they're 
going to have to change their code in a particular way after a future 
release seems worth breaking the builds of a hypothetical few users who 
use -Werror or equivalent.)

-- 
Richard