Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote: > > Need an idea on how to proceed here. There is a problem related to updating > plugins here. We have renamed feature with one unrenamed plugin. How > to we avoid problem when switching from org.spearce to org.eclipse > > One option is to release a v0.4.1 (which we should do anyway), which is the last > version from master before the split. For technical reasons this will be > a branch since the split occurred already. > > That 0.4.1 feature should require jgit < 0.5. Then we jgit to v0.5 and > make org.eclipse.egit require jgit >= 0.5 > > Having two EGit features will be confusing. You get two of everything. E.g. > Team>Share will have two Git's to choose from, but you cannot tell which > is which. > > That said, having both could be a feature, since it (didn't really try it), would > be possible to switch between new and old workspaces and get the plugin > configured for that workspace. The wierdness make me suggest we do > not do this. If we really want it we could choose to create a proxy plugin > for attaching old workspaces to the new plugins. Yikes. I didn't even consider this. My own workspaces freaked out at the change, but I just deleted the projects from the workspace, re-imported them, and re-attached them to the new team provider. I never even gave it a second thought. You're right, we should have a better plan for existing deployments. Its a good thing I didn't just shove this into the tree, even though it seemed simple on the surface. Too simple. :-) I like the 0.5 cut to define jgit versions pre/post split. But I'm really not sure what to do about the rename on the EGit team provider for existing workspaces. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html