{"thread":{"id":"19857","subject":"Re: [EGIT PATCH] Rename org.spearce.egit -> org.eclipse.egit","startedAt":"2009-06-18T23:20:29Z","lastAt":"2009-06-19T08:47:42Z","messageCount":3,"participants":["Robin Rosenberg","Shawn O. Pearce","Alex Blewitt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"116605","messageId":"200906190120.29915.robin.rosenberg@dewire.com","threadId":"19857","inReplyTo":"1245253576-13324-1-git-send-email-spearce@spearce.org","subject":"Re: [EGIT PATCH] Rename org.spearce.egit -> org.eclipse.egit","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2009-06-18T23:20:29Z","receivedAt":"2009-06-18T23:20:29Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\nNeed an idea on how to proceed here. There is a problem related to updating\nplugins here. We have renamed feature with one unrenamed plugin. How\nto we avoid problem when switching from org.spearce to org.eclipse\n\nOne option is to release a v0.4.1 (which we should do anyway), which is the last\nversion from master before the split. For technical reasons this will be\na branch since the split occurred already.\n\nThat 0.4.1 feature should require jgit < 0.5. Then we jgit to v0.5 and\nmake org.eclipse.egit require jgit >= 0.5\n\nHaving two EGit features will be confusing. You get two of everything. E.g.\nTeam>Share will have two Git's to choose from, but you cannot tell which\nis which.\n\nThat said, having both could be a feature, since it (didn't really try it), would\nbe possible to switch between new and old workspaces and get the plugin\nconfigured for that workspace. The wierdness make me suggest we do\nnot do this. If we really want it we could choose to create a proxy plugin\nfor attaching old workspaces to the new plugins.\n\n-- robin\n"},{"id":"116606","messageId":"20090618232431.GR11191@spearce.org","threadId":"19857","inReplyTo":"200906190120.29915.robin.rosenberg@dewire.com","subject":"Re: [EGIT PATCH] Rename org.spearce.egit -> org.eclipse.egit","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-06-18T23:24:31Z","receivedAt":"2009-06-18T23:24:31Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg wrote:\n> \n> Need an idea on how to proceed here. There is a problem related to updating\n> plugins here. We have renamed feature with one unrenamed plugin. How\n> to we avoid problem when switching from org.spearce to org.eclipse\n> \n> One option is to release a v0.4.1 (which we should do anyway), which is the last\n> version from master before the split. For technical reasons this will be\n> a branch since the split occurred already.\n> \n> That 0.4.1 feature should require jgit < 0.5. Then we jgit to v0.5 and\n> make org.eclipse.egit require jgit >= 0.5\n> \n> Having two EGit features will be confusing. You get two of everything. E.g.\n> Team>Share will have two Git's to choose from, but you cannot tell which\n> is which.\n> \n> That said, having both could be a feature, since it (didn't really try it), would\n> be possible to switch between new and old workspaces and get the plugin\n> configured for that workspace. The wierdness make me suggest we do\n> not do this. If we really want it we could choose to create a proxy plugin\n> for attaching old workspaces to the new plugins.\n\nYikes. I didn't even consider this. My own workspaces freaked out\nat the change, but I just deleted the projects from the workspace,\nre-imported them, and re-attached them to the new team provider.\nI never even gave it a second thought.\n\nYou're right, we should have a better plan for existing deployments.\n\nIts a good thing I didn't just shove this into the tree, even though\nit seemed simple on the surface. Too simple. :-)\n\nI like the 0.5 cut to define jgit versions pre/post split. But I'm\nreally not sure what to do about the rename on the EGit team provider\nfor existing workspaces.\n\n-- \nShawn.\n"},{"id":"116616","messageId":"7270CCF7-45F2-46DE-BD4D-41D921852947@gmail.com","threadId":"19857","inReplyTo":"20090618232431.GR11191@spearce.org","subject":"Re: [egit-dev] Re: [EGIT PATCH] Rename org.spearce.egit -> org.eclipse.egit","fromName":"Alex Blewitt","fromEmail":"alex.blewitt@gmail.com","sentAt":"2009-06-19T08:47:42Z","receivedAt":"2009-06-19T08:47:42Z","isPatch":true,"sender":{"key":"alex.blewitt@gmail.com","avatar":"https://gravatar.com/avatar/fb95a3b593b290f03a8d3b022c20b2825205702c5651f731f65d33512dfe6ab2?d=mp&s=160"},"body":"One possibility is to provide a compatibility bundle such that the old \nAPI subclasses the refactored classses. That way, existing projects \nwill continue to work.\n\nHowever, it is quite likely to be difficult to do it with 100% success \nso another option might be to provide an upgrade option, only visible \nto the older projects , which will do the change in place.\n\nBut since it's a fairly major change, and that people will have to go \nsomewhere else to get the plugins etc, it is probably a more efficient \nuse of time to just make a note in the release notes about the change \nand let people upgrade themselves.\n\nAlex\n\nSent from my (new) iPhone\n\nOn 19 Jun 2009, at 00:24, \"Shawn O. Pearce\" wrote:\n\n> Robin Rosenberg wrote:\n>>\n>> Need an idea on how to proceed here. There is a problem related to \n>> updating\n>> plugins here. We have renamed feature with one unrenamed plugin. How\n>> to we avoid problem when switching from org.spearce to org.eclipse\n>>\n>> One option is to release a v0.4.1 (which we should do anyway), \n>> which is the last\n>> version from master before the split. For technical reasons this \n>> will be\n>> a branch since the split occurred already.\n>>\n>> That 0.4.1 feature should require jgit < 0.5. Then we jgit to v0.5 \n>> and\n>> make org.eclipse.egit require jgit >= 0.5\n>>\n>> Having two EGit features will be confusing. You get two of \n>> everything. E.g.\n>> Team>Share will have two Git's to choose from, but you cannot tell \n>> which\n>> is which.\n>>\n>> That said, having both could be a feature, since it (didn't really \n>> try it), would\n>> be possible to switch between new and old workspaces and get the \n>> plugin\n>> configured for that workspace. The wierdness make me suggest we do\n>> not do this. If we really want it we could choose to create a proxy \n>> plugin\n>> for attaching old workspaces to the new plugins.\n>\n> Yikes. I didn't even consider this. My own workspaces freaked out\n> at the change, but I just deleted the projects from the workspace,\n> re-imported them, and re-attached them to the new team provider.\n> I never even gave it a second thought.\n>\n> You're right, we should have a better plan for existing deployments.\n>\n> Its a good thing I didn't just shove this into the tree, even though\n> it seemed simple on the surface. Too simple. :-)\n>\n> I like the 0.5 cut to define jgit versions pre/post split. But I'm\n> really not sure what to do about the rename on the EGit team provider\n> for existing workspaces.\n>\n> -- \n> Shawn.\n> _______________________________________________\n> egit-dev mailing list\n> egit-dev@eclipse.org\n> https://dev.eclipse.org/mailman/listinfo/egit-dev\n"}]}