Re: [egit-dev] Re: [EGIT PATCH] Rename org.spearce.egit -> org.eclipse.egit

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@gmail.com> schrieb am Fr, 19.6.2009:

Von: Alex Blewitt [off-list ref]
Betreff: Re: [egit-dev] Re: [EGIT PATCH] Rename org.spearce.egit -> org.eclipse.egit
An: "EGit developer discussion" [off-list ref]
CC: "Robin Rosenberg" <redacted>, "git@vger.kernel.org" <redacted>, "egit-dev@eclipse.org" <redacted>
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" [off-list ref]
wrote:

quoted

Robin Rosenberg [off-list ref]

wrote:

quoted

quoted

Need an idea on how to proceed here. There is a

problem related to updating

quoted

quoted

plugins here. We have renamed feature with one

unrenamed plugin. How

quoted

quoted

to we avoid problem when switching from

org.spearce to org.eclipse

quoted

quoted

One option is to release a v0.4.1 (which we should

do anyway), which is the last

quoted

quoted

version from master before the split. For

technical reasons this will be

quoted

quoted

a branch since the split occurred already.

That 0.4.1 feature should require jgit < 0.5.

Then we jgit to v0.5 and

quoted

quoted

make org.eclipse.egit require jgit >= 0.5

Having two EGit features will be confusing. You

get two of everything. E.g.

quoted

quoted

Team>Share will have two Git's to choose from,

but you cannot tell which

quoted

quoted

is which.

That said, having both could be a feature, since

it (didn't really try it), would

quoted

quoted

be possible to switch between new and old

workspaces and get the plugin

quoted

quoted

configured for that workspace. The wierdness make

me suggest we do

quoted

quoted

not do this. If we really want it we could choose

to create a proxy plugin

quoted

quoted

for attaching old workspaces to the new plugins.

Yikes.  I didn't even consider this.  My own

workspaces freaked out

quoted

at the change, but I just deleted the projects from

the workspace,

quoted

re-imported them, and re-attached them to the new team

provider.

quoted

I never even gave it a second thought.

You're right, we should have a better plan for

existing deployments.

quoted

Its a good thing I didn't just shove this into the

tree, even though

quoted

it seemed simple on the surface.  Too

simple.  :-)

quoted

I like the 0.5 cut to define jgit versions pre/post

split.  But I'm

quoted

really not sure what to do about the rename on the

EGit team provider

quoted

for existing workspaces.

--Shawn.
_______________________________________________
egit-dev mailing list
egit-dev@eclipse.org
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html