Bugzilla – Full Text Bug Listing
| Summary: | Eclipse should warn if opened workspace is from newer version of Eclipse | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Krzysztof Daniel <krzysztof.daniel> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | daniel_megert, jamesblackburn+eclipse, krzysztof.daniel, remy.suen, serge, sptaszkiewicz, yevshif |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Krzysztof Daniel
Surely this only needs to be done when there is a real non-forward/backward compatible change? I don't see how an arbitrary health warning is useful if there isn't such a breaking change. Certainly in our environment we're keen to maintain compatibility between releases. James, backward compatibility is not a problem. Forward compatibility is. The simplest example: Imagine Eclipse 3.7 gets a new, fancy view. User opens that view in a workspace, then accidentally opens the workspace in an old Eclipse. Eclipse complain about missing view and alters the perspective. Next time you will start Eclipse 3.7 you will have no view opened. User data (perspective configuration) was lost. The same scenario applies to almost any component in Eclipse - older versions may not read the data of the newer versions, and in certain cases they can interfere with newer mechanism. Workspace migration is a common thing, but migrating workspace back and forth is not, since Eclipse does not offer forward compatibility in general. We need to protect workspace against that use case. Hmmm. The specific case of a non-existent view occurs whenever the eclipse configuration changes. With multiple configurations containing different features, what you've described is a common problem and not related to forward / backward compatibility. (In reply to comment #2) > Workspace migration is a common thing, but > migrating workspace back and forth is not, since Eclipse does not offer forward > compatibility in general. Well we do this a fair bit. We track core.resource HEAD much more closely than the release train, and being able to open workspaces with an older and newer resources plugin is important. Note the workspace tree is already versioned, and the LocalMetaArea has been modified in a forward / backward compatible way up till now. What additional state did you think needs versioning? How will such a warning help users? (In reply to comment #3) > What additional state did you think needs versioning? How will such a warning > help users? I am not sure if any changes in resources code are really required. I would expect a message dialog, similar to the workspace is in use, which says: "This workspace may not function properly because it was modified by newer version of the product. If you choose to continue, the workspace might be corrupted." [Continue][Cancel] (In reply to comment #4) > I am not sure if any changes in resources code are really required. I would > expect a message dialog, similar to the workspace is in use, which says: But if nothing has changed then surely opening the workspace is safe? I'm just trying to understand how a user would respond to that warning. If there's been a breaking change to the workspace tree, then that version should be incremented and we should disallow opening altogether. If not, by definition it's safe to open the workspace. From my POV most of the workspace metadata is local, transient and can be regenerated. The contents of the .project file are more troublesome as opening a project in an older eclipse may cause new elements and attributes to be lost (and there is no versioning here...). If problems have occurred due to incorrect versioning then I agree those issues should be tackled. However surely it's wrong to add a generic health warning just-in-case? While we may know whether it's safe or not to go backwards, without any further detail there's no way a user can make a sensible decision. I also think it's important that we don't break forwards compatibility needlessly. If we do it should be clear to all concerned that this has happened, and in that case pro-actively disallow opening the new workspaces. Got your point. So what about an extension point/service which would allow product to decide if the warning should be displayed or not? This bug relates as well to bug 293604, which covers backward/forward compatibility with the .project file. There is some very basic support for this kind of functionality, but it refers only to hardcoded versions of workspace and ide. I think that mechanism could be generalized and open for external validators: org.eclipse.ui.internal.ide.application.IDEApplication.checkValidWorkspace(Shell, URL) *** This bug has been marked as a duplicate of bug 423882 *** |