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.
-- robin
Robin Rosenberg [off-list ref] 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.
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:
Robin Rosenberg [off-list ref] wrote:
quoted
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@eclipse.org
https://dev.eclipse.org/mailman/listinfo/egit-dev