Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EMF Compare/Specifications/EditingTextualAttribute"

Line 8: Line 8:
 
keep. We will relax the read-only constraint on textual compare viewer. As soon as the left or the right side is
 
keep. We will relax the read-only constraint on textual compare viewer. As soon as the left or the right side is
 
edited, the associated difference will be marked as rejected.
 
edited, the associated difference will be marked as rejected.
 
_Relevant tickets_ (links to the Bugzilla tickets which are related to the change):
 
  
 
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=398083 Bug 398083] - Allow the edition textual attribute
 
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=398083 Bug 398083] - Allow the edition textual attribute
Line 15: Line 13:
 
== Introduction  ==
 
== Introduction  ==
  
This section should contain a summary of the proposed evolution, including why it is needed. Ideally it should be self-contained so that non-developers can get a quick overview of the evolution without reading the detailed specification.  
+
TODO: This section should contain a summary of the proposed evolution, including why it is needed. Ideally it should be self-contained so that non-developers can get a quick overview of the evolution without reading the detailed specification.  
  
 
== Detailed Specification  ==
 
== Detailed Specification  ==
  
This section contains the "meat" of the document. Its structure will depend on the evolution itself, but it should contain:  
+
TODO: This section contains the "meat" of the document. Its structure will depend on the evolution itself, but it should contain:  
  
 
*a clear description of the objective, i.e. why the evolution is needed.  
 
*a clear description of the objective, i.e. why the evolution is needed.  
Line 26: Line 24:
  
 
== Backward Compatibility and Migration Paths  ==
 
== Backward Compatibility and Migration Paths  ==
 
Every one of the sections below should be present. Even if there is no corresponding change (for example no API change), it should exist to mention explicitly "This evolution does not change any API."
 
  
 
=== Metamodel Changes  ===
 
=== Metamodel Changes  ===
  
Document any change to the Viewpoint metamodel. If they require a migration operation, mention it and describe the general idea of how migration process. If any information can be lost during the migration, mention it clearly. If validation rules must be added/modified, mention it also.  
+
This evolution does not change any metamodel.
  
 
=== API Changes  ===
 
=== API Changes  ===
  
List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.  
+
TODO: List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.  
  
 
=== User Interface Changes  ===
 
=== User Interface Changes  ===
  
List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.  
+
TODO: List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.  
  
 
=== Documentation Changes  ===
 
=== Documentation Changes  ===
  
List every documentation needing an update here, starting by the New and Noteworthy documentation.  
+
TODO: List every documentation needing an update here, starting by the New and Noteworthy documentation.  
  
 
== Tests and Non-regression strategy  ==
 
== Tests and Non-regression strategy  ==
  
This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.  
+
TODO: This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.  
  
 
== Implementation choices and tradeoffs  ==
 
== Implementation choices and tradeoffs  ==
  
Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.
+
TODO: Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.
  
 
[[Category:EMF Compare]]
 
[[Category:EMF Compare]]

Revision as of 04:58, 18 January 2013

Evolution Specification: Allow the editing of textual attribute

Current status is DRAFT

Preamble

Often, when comparing textual attribute, neither the local nor the remote value is the one the user wants to keep. We will relax the read-only constraint on textual compare viewer. As soon as the left or the right side is edited, the associated difference will be marked as rejected.

Introduction

TODO: This section should contain a summary of the proposed evolution, including why it is needed. Ideally it should be self-contained so that non-developers can get a quick overview of the evolution without reading the detailed specification.

Detailed Specification

TODO: This section contains the "meat" of the document. Its structure will depend on the evolution itself, but it should contain:

  • a clear description of the objective, i.e. why the evolution is needed.
  • a justification of the approach chosen. If other approaches were considered and rejected, document it for future reference.
  • limits: things that are out of the scope of the evolution.

Backward Compatibility and Migration Paths

Metamodel Changes

This evolution does not change any metamodel.

API Changes

TODO: List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.

User Interface Changes

TODO: List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.

Documentation Changes

TODO: List every documentation needing an update here, starting by the New and Noteworthy documentation.

Tests and Non-regression strategy

TODO: This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.

Implementation choices and tradeoffs

TODO: Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.

Back to the top