Hmm, as an eclipse-plugin-prog dummy, I can't see so much problems around. The old binaries are still there. The new binaries are essentially a new scm plugin. Where do they interfere? They will have new names, config sections, etc isn't? We could also ship an update to the old plugin introducing a clear name 'SpearceGit' or something. So it can easily be distinguished for those who need old projects in parallel. In a few months time from now, almost all people will only have the new org.eclipse plugin installed. And thus who have both old and new plugins installed should know how to select the proper one that way. LieGrue, strub --- Alex Blewitt <alex.blewitt@xxxxxxxxx> schrieb am Fr, 19.6.2009: > Von: Alex Blewitt <alex.blewitt@xxxxxxxxx> > Betreff: Re: [egit-dev] Re: [EGIT PATCH] Rename org.spearce.egit -> org.eclipse.egit > An: "EGit developer discussion" <egit-dev@xxxxxxxxxxx> > CC: "Robin Rosenberg" <robin.rosenberg@xxxxxxxxxx>, "git@xxxxxxxxxxxxxxx" <git@xxxxxxxxxxxxxxx>, "egit-dev@xxxxxxxxxxx" <egit-dev@xxxxxxxxxxx> > Datum: Freitag, 19. Juni 2009, 10:47 > One possibility is to provide a > compatibility bundle such that the old API subclasses the > refactored classses. That way, existing projects will > continue to work. > > However, it is quite likely to be difficult to do it with > 100% success so another option might be to provide an > upgrade option, only visible to the older projects , which > will do the change in place. > > But since it's a fairly major change, and that people will > have to go somewhere else to get the plugins etc, it is > probably a more efficient use of time to just make a note in > the release notes about the change and let people upgrade > themselves. > > Alex > > Sent from my (new) iPhone > > On 19 Jun 2009, at 00:24, "Shawn O. Pearce" <spearce@xxxxxxxxxxx> > wrote: > > > 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. > > _______________________________________________ > > egit-dev mailing list > > egit-dev@xxxxxxxxxxx > > https://dev.eclipse.org/mailman/listinfo/egit-dev > -- > 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 > -- 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