[Mono-devel-list] A Plea for CVS Sanity

[Jonathan Pryor]

For the sanity of those of us who don't live & breath every area of mono
(which is probably most of us, since we love specialization so much), it
would probably be very useful to mark deprecated sections of the tree
as, well, deprecated. :-)

For example, mcs/class has two IBM DB/2 providers: IBM.Data.DB2 and
Mono.Data.DB2Client.  Which should we use?

Likewise for Mono.Data.PostgreSqlClient vs. Npgsql, and Mono.Data.MySql
vs. ByteFX.Data.

The problem is that those of us with short memories (read: me, and
probably others) aren't going to remember which of these is the correct
one to use.  It doesn't help matters that *all* of these libraries were
shipped with Mono 0.31, so looking at what's in the RPM doesn't help.

In addition to having this information located in the mailing list
archives, this information should also be in CVS.

I would thus propose two things:

1.  When an assembly (or CVS module, whichever) gets deprecated (or
    otherwise replaced with a maintained alternative), add a DEPRECATED 
    file to CVS within the topmost appropriate directory.  Within
    DEPRECATED, enter the assembly/module that should be used instead,
    if appropriate.  For example, if IBM.Data.DB2 is deprecated, you 
    should add the file "mcs/class/IBM.Data.DB2/DEPRECATED" to CVS.

2.  Don't build and distribute deprecated assemblies.

If this isn't appropriate (if, for instance, we plan on migrating away
from one library but are unable to yet), AT LEAST place a file
explaining the scenario, when you should use the older library, when you
should use the newer library, and otherwise DOCUMENT what's happening.  

It shouldn't take searching through the list archives (or asking the
list) to determine which assemblies are current.

Thanks,
 - Jon