Re: Deprecation policy question

James Aylett wrote:
>>> The thing is that I'm not convinced there's a
problem with bumping the
>>> minor version when we start a deprecation
cycle. I don't see how that
>>> can hurt, and it allows everything else to work
smoothly.
>> I think, in practice, this would simply mean that
almost every release 
>> was a minor release.
> 
> Really? If our API is really that volatile, and will
continue to be
> so, then I'd argue we have a different problem.

Hmm.  Well, I probably overstated the case.  1.0.1 and 1.0.2
contained 
no new deprecations.  Historically, 1.0.0, 0.9.6 and 0.9.0
saw 
deprecations in the core (though we weren't really trying to
follow any 
particular policy before 1.0.0, so the historical
information is arguable).

The suggestion from you, and also from Jean-Francois that we
should 
actually make a minor release whenever we feel that we want
to add a 
deprecation (as opposed to waiting until we were going to
make a minor 
release anyway, and then add deprecations) sounds plausible
to me.  That 
way, we don't have any delay in putting the warning macro in
place, and 
also have no delay.

The downside is that it becomes less clear when it's okay to
break the 
ABI and API.  Using major releases to denote that is an
option, but 
means we'll probably have about 1 major release a year,
which somehow 
seems wrong.

-- 
Richard

_______________________________________________
Xapian-discuss mailing list
Xapian-discusslists.xapian.org
http://lists.xapian.org/mailman/listinfo/xapian-discuss

On Mon, Sep 24, 2007 at 05:55:18PM +0100, Richard Boulton
wrote:

> The downside is that it becomes less clear when it's
okay to break the 
> ABI and API.  Using major releases to denote that is an
option, but 
> means we'll probably have about 1 major release a year,
which somehow 
> seems wrong.

Hmm, yeah. My view here:

 * breaking the ABI can be done at minors; since there will
now be a
   /reasonable/ chance that a minor will deprecate
something, you
   probably need to do code changes to keep perfectly up to
date, so
   recompiling isn't really an issue

 * breaking the API can be done at majors; it's possible we
could do
   it exceptionally at minors, by concensus on the list
where we know
   that the number of impacted users is low, and the
negative impact
   is considerably less than the net gain -- however it's
easier to
   just break the API only at majors (not counting
deprecations)

 * breaking the db format should (a) only be done at majors,
(b)
   hopefully won't happen again anyway 

J

-- 
/-----------------------------------------------------------
---------------
  James Aylett                                              
   xapian.org
  jamestartarus.org                              
uncertaintydivision.org

_______________________________________________
Xapian-discuss mailing list
Xapian-discusslists.xapian.org
http://lists.xapian.org/mailman/listinfo/xapian-discuss