Re: API for next stable release of base library

[Richard Frith-Macdonald]

On 18 Oct 2006, at 14:47, Marko Riedel wrote:

> Hello there,
>
> thanks for the clarification. I guess there is no problem as long  
> as the
> deprecations are well-documented and posted to the list, thus giving
> authors an opportunity to adapt their code.

My aim is to mark deprecations as follows ...

1. in the headers ... which should automatically feed through into  
the documentation.
2. for functions, mark them with the 'deprecated' attribute so the  
compiler will issue a warning if they are used.
3. for methods, use GSOnceMLog() so that a single warning will be  
printed at runtime if they are used (I wish the compiler supported  
the 'deprecated' attribute for methods).

This should ensure that developers get *at least* a full release  
cycle to adapt code (eg. something deprecated in 1.14.0 should be  
present in both 1.14.0 and 1.15.0).

However, I would like to get any deprecations in place as soon as  
possible ... so developers using svn will notice them and we can  
discuss on the mailing list whether deprecation is the right thing to  
do and/or if we should be moving some functionality rather than  
simply removing it.  We can of course undeprecate something at any  
point before it is removed, but I think it's better to sort things  
out before the next release makes any deprecations 'formal', rather  
than change our minds after.