Pat McCarthy

I'm back (was watching our Dan do his thing while I was teaching).
Yes, plug-ins just copied into the \plugins dir work, but yes they are 'unmanaged'. Course if you copied both a plugin and a feature that referenced the plugin into the appropriate \plugins and \feature dirs it would both work and be managed, but you would also have to accept this change before Eclipse showed it to you in the runtime environment. Features ask your permission, plugins on their own just sneak right in.
I'm still a bit confused about what you did vs what others did. I think I know what happened to you/your team?
Given :
1) plugin id=a.b.c version=1.0.0
2) plugin id=a.b.c version=1.0.1
3) feature id=a.b.c version=1.0.1
If item 1 is just copied into the \plugins dir it works.
If items 2 and 3 are copied in, the new plugin a.b.c version 1.0.1 will be there instead, as long as the configuration change is accepted.
When you start eclipse after the copy of 2/3, it will ask you if you want this new code configured. If you say yes and restart, you see the new plugin (item 2, v1.0.1). If you say no, or yes but do not restart, you see the old plugin (item 1, v1.0.0).
If you later deconfigure the feature (item 3), you will disable the referenced plugin (item 2), but the unreferenced plugin (item 1, v1.0.0) will surface again. As this plugin version is not referenced by the disabled feature it can now rejoin the Eclipse configuration. Just as it snuck in before (without a feature), it comes back.
So if people have both plugins 1 and 2 in their dir, but see 1, it might be that they did not accept the config change for 2 as represented by the feature that references that plugin version or they disabled the feature and the old plugin came back....
All of this can be a bit easier to manage if you both always use features and keep your code in a separate dir and use link files (see Creating a Eclipse Configuration You Can Manage).
Easier to see your code that way and maybe delete the offending/unmanaged plugins once you start using features.

k - the feature/plugin list shows you have both a feature and plugin named 'com.rwd.bangoo', which is fine.
The config also shows that the active feature/plugin is version 2.0.1.
Back to your original question/problem:
--
"Having said that, here's the problem - It seems the old version is not really disabled. The plugin adds a menu item that changed between the version everyone has and the one I want to make available. When I tested it, though, the old menu item did not disappear; I got both menu items."
--
What change was made? What does key part of the plugin.xml contain in version 2.0.0 vs 2.0.1?

We'd love to have you RTB (Read the book) as this process is covered in a chapter and exercise. The exercise can be followed using your plug-in without much difficulty.
The question I'd ask given you say the old version is still around - does the new version have the same plug-in ID and a different version ID?
Get the config details for your runtime system with both plugins and post here.. You do Help>About (product name) and then click on the Configuration Details button. Will list lots of details about your system including plugins that are known and the update manager log of changes.

In another post I was responding to a question about Update Manager and plugin install and said I'd post a description of how I manage my environment.
See (Loading Plugins and maintaining the Eclipse Environment).
I like using the extension capability of Eclipse to install Eclipse examples, plug-ins from others, and even my own plug-ins. That is, I have a \links directory in my Eclipse install dir that points to other dirs that include eclipse\features and eclipse\plugins dirs. When started, Eclipse sees the link file, follows it to find the additional code, and includes it in the config for a new workspace. For an existing workspace Eclipse would detect the new link file and prompt for a decision on if the new features should be included in the current configuration. You can say yes, no-not now, or no-not every (so take them off the list of pending changes).
This seems complex at first, but it is not that hard. I just finished reworking my environment to use Eclipse 2.1.1 full-time. In doing so I created a structure of Eclipse Examples, Solutions as shared in our book, other plug-ins from other sources, and my private plug-ins. The full dir tree looks something like this:
E:\Eclipse-2.1.1\eclipse - Eclipse itself - the full SDK download
Installed features are kept in a different dir tree:
E:\Eclipse-2.1.1\installedFeatures\eclipseExamples - dir for where I unzipped the Eclipse examples
E:\Eclipse-2.1.1\installedFeatures\JSGuide - dir where I have several of the book solutions
E:\Eclipse-2.1.1\installedFeatures\omondo - dir where I have a copy of the free omondo code
E:\Eclipse-2.1.1\installedFeatures\privateTools - dir where I have my code
Each of the above dirs has an eclipse\features and eclipse\plugins directory where the associated features and plugins are kept.
Link files identify dirs where more features/plugins can be found. So I have these dirs in my Eclipse install:
E:\Eclipse-2.1.1\eclipse\links - dir for link files I use to tell Eclipse where to find more code
For example:
E:\Eclipse-2.1.1\eclipse\links\eclipseExamples.link
E:\Eclipse-2.1.1\eclipse\links\ installedFeatures.link
E:\Eclipse-2.1.1\eclipse\links-out - dir where I hide link files I don't want Eclipse to see just yet
Features/plugins found in a dir tree identified by a link file are processed by Eclipse at startup.
By convention a link file should have a name of feature-id.link, where feature-id is the root feature. Any name will work, but formal products that are installed/configured as extensions should use the expected naming pattern.
For example, the eclipseExamples.link file contains (no spaces at end):
path=E:/Eclipse-2.1.1/installedFeatures/eclipseExamples
If I add a link file to the \links dir later, the change will be detected at startup (splash screen flashes twice) and then if I have features involved I'll get prompted on if I want the change added to the current configuration. If there are only plug-ins, or plug-ins not referenced by a feature, then they are just added to the current config (as unmanaged plugins).
I find that this approach allows me to delete my Eclipse dir when required (I've fiddled it a bit more than I should on occasion), but keep all my installed features/plugins as-is, and if I don't delete the /links and /links-out dirs, I can quickly get my code back into a new Eclipse install.
Un-install is just a matter of disabling the feature (if features are used to manage the plug-ins) or moving the link from \links to \links-out. The next start/stop of the workbench will cause them to be dropped.
If you want to see all the internal bits - find your workspace\.metadata\.config\platform.cfg file - it will show you entries for each install site (platform, linked sites, and update manager install sites). Not a file to edit, but on that might help you figure out where a plug-in in your config was actually installed.
[ July 19, 2003: Message edited by: Pat McCarthy ]

This whole area of installing plug-ins is tricky.
First-off, if you used Update Manager to install a feature and its associated plug-ins, they are installed on your machine. The update manager downloads them from the URL you opened (where a site.xml file was found to define the features that could be installed) and then writes them to the install site you identified.
The default install site is the current Eclipse directory. This means they are just added to your current \features and \plugins dirs. With this choice, every workspace you open will 'see' those plug-ins. If you choose a new install site for update manager to use then the features/plugins installed are only visible to the workspace you used during the install. If you look down in the workspace/.metadata/.config dir you would fine a file named platform.cfg that is the workspace memory of that Update Manager install.
That said, you can dump plug-ins (and I hope a feature too) into the eclipse\plugins and eclipse\features directories, but I wouldn't...
The right approach depends on what you want to do and is it for one workspace or the full eclipse install. This is a detailed discussion, and one I'll post soon as a new entry.

Hello there.
What is your definition of 'exclude the folder'?
Do you mean:
Hide it from a repository?
Hide it from the JDT compiler?
Not import the folder?
(depending on how you migrated your project to Eclipse)