RE: Discussion: Formalizing the deprecation process in GDB

["Dave Korn" <dk@artimi.com>]

> -----Original Message-----
> From: Joel Brobecker 
> Sent: 07 October 2004 19:01

> Anyway, like in any project, there is a learning curve, and that
> curve can be reduced to a certain degree by good documentation.
> However, you have to balance the amount of document your write
> and *maintain* with the amount of work this saves for some potential
> contributor. 

  Yeh, of course, and being a relative newbie, it's hard for me to tell how
much (if any) of the difficulty I face is down to not having the right
balance (or just not enough docs), and how much of it is just inevitable
learning curve stuff.

>  I think that maintaining the list of deprecated features
> in a separate document is going to be a large amount of work.
> GDB is changing so fast.  

  Erm... things that get deprecated don't often get un-deprecated, do they?
Wouldn't it largely be a matter of just adding a couple of lines each time
something gets deprecated, just enough to say "All this stuff is now
replaced by the new XXXX mechanism; use XXXXX_do_whatever in place of
deprecated_OLDXXXXXX_do_somethingelse, or see gdb-XXXXX.h for more
information."  Or words to that effect.  Shouldn't it be possible for the
old entries in that document to then remain more or less static?  I'm
envisaging something that's a bit like a specialized changelog, but rather
than file-by-file and function-by-function descriptions of changes, which
are a bit low-level, it would have a list of deprecated functionalities and
their replacements.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....