oh, btw, we were to implement a install/uninstall process when i was in WP, but that was never done when i left… the process is quite simple, we simply have a array of tables or fields to generate, that are installed/uninstalled on due time. the coder does not have to generate the whole process, just have to enter the fields and tables in the right way in the install file.
see how we do it with vBulletin:
$dbalter->fetch_table_info(‘user’);
$dbalter->add_field(array(
‘name’ => ‘itrader_total’,
‘type’ => ‘int’,
‘length’ => ’10’,
‘null’ => false,
‘default’ => ‘0’
), false);
… on uninstall of the product, the process is the same:
$dbalter->fetch_table_info(‘user’);
$dbalter->drop_field(‘itrader_total’);
I agree with you completely and I will certainly keep in mind in my next plugin 
It should not be difficult to implement an uninstall/cleanup process to clean all the databases.
Thanks for pointing it here in the community.Hopefully ,many more people will be interested in doing so.
thanks Brajesh for the understanding…
i’m not at the level to release my own work on BP yet, as i have to finalise some tasks in the vBulletin universe right now, but i hope to be able to code some plugins for BP and i will surely have a install/uninstall process if my stuff needs dB edits… *(usually not though)… 
Bigger problem is that some of the plugin activation/deactivation hooks don’t work or aren’t reliable with WPMU, which makes things difficulty or tricky to track down when something breaks.
@nexia
There have been relatively recent (sometimes heated) debates about the issue of plugin activation and management in the WP community. The issue you describe is just one of several that need to be addressed.
I posted this awhile back on someone’s blog post:
Plugin conflicts caused by activation sequence order are becoming more of an issue–especially with the sophisticated BuddyPress plugin. More experienced plugin devs do add code to check for the installation and activation of certain core plugins before their plugin is activated, but that is not fool proof.
I believe there is a better way to do this. There should be reserved blocks of numbers set aside for key components (plugins). These numbers would be lower in the activation sequence, therefore gaining higher priority. So, BuddyPress for instance, would always be assigned a reserved activation sequence number that is lower than any 3rd-party plugin that is developed to run on top of BuddyPress. The other way to do this is parent-child dependancies. All BuddyPress plugins would be child plugins to the parent component.
the problem with all these protocols is not to build them, but to make them followed by all coders. we faced this on other projects, and most of the time we abandon this due to the lack of consistancy in the release process: no audit, no verification staff, nobody to keep the database of plugins uptight…
as a good example, my own work for vBulletin is always rated higher in the priority list because they are core-modifications, not featurettes. site owners could always change the priority level of my addons if they want *(for no logical reason)… most of the products coded in the vBulletin market are priority 5, and they conflict between them, because nobody is able to set their code to not conflict with others… and there is no staff available to check all thes products to see if they fit by version or by conflict… so it’s a real mess.
the only real solution for these install/protocols would be to have a team that keep all these releases clear of conflicts… but i’m sure it’s far from being possible, as everybody here is volunteer… people can not simply spend all their time checking all and every version to see if they contain all the processes and follow the exact WP protocol to the letter…
and most of the time, the ones who are not happy with the need to apply protocols are the ones who don’t care, they code something for their needs and think they can help if they release their work, no matter the rules. and even if we’re in the GPL thing, coders don’t always wish to see their work reworked.
i face this kind of brainstorm debate right now for a project i’m building… we face the need to control about everything that “may” be released by third party coders… we have outsourcers, but also fans who will release their work, and we want to make sure everybody have the hability to code properly, or we face the switch: we recode it, or we reject it…
