diff --git a/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.39/faq.html b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.39/faq.html new file mode 100644 index 00000000000..57dc4b16111 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.39/faq.html @@ -0,0 +1,19 @@ + + +
+ + + ++ So far Eclipse did not change incompatibly between 4.38 and 4.39 in ways that affect + plug-ins. Plug-ins that ran on 4.38 should run on 4.39 without any problems. +
+ + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.39/recommended.html b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.39/recommended.html new file mode 100644 index 00000000000..5c67a669708 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.39/recommended.html @@ -0,0 +1,22 @@ + + + + + + ++ This section describes changes that are required if you are trying to change + your 4.38 plug-in to adopt the 4.39 mechanisms and APIs. +
+ +This guide covers migrating Eclipse JDT 4.38 plug-ins to Eclipse JDT 4.39.
+One of the goals of Eclipse 4.39 was to move Eclipse forward while remaining compatible + with previous versions to the greatest extent possible. That is, plug-ins written + against the Eclipse 4.38 APIs should continue to work in 4.39 in spite of the + API changes.
+The key kinds of compatibility are API contract compatibility and binary compatibility. + API contract compatibility means that valid use of 4.38 APIs remains valid for + 4.39, so there is no need to revisit working code. Binary compatibility means + that the API method signatures, etc. did not change in ways that would cause + existing compiled ("binary") code to no longer link and run with the + new 4.39 libraries.
+While every effort was made to avoid breakage, there are a few areas of incompatibility or new + APIs that should be adopted by clients. + This document describes those areas and provides instructions for migrating 4.38 plug-ins to + 4.39.
++ Eclipse changed in incompatible ways between 4.38 and 4.39 in ways that affect + plug-ins. The following entries describe the areas that changed and provide + instructions for migrating 4.38 plug-ins to 4.39. Note that you only need to look + here if you are experiencing problems running your 4.38 plug-in on 4.39. +
++See also the list of deprecated API removals for this release. +
+ + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.39/recommended.html b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.39/recommended.html new file mode 100644 index 00000000000..accee036249 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.39/recommended.html @@ -0,0 +1,23 @@ + + + + + + + +This section describes changes that are required if you are + trying to change your 4.38 plug-in to adopt the 4.39 mechanisms and + APIs.
+ + + + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_39_porting_guide.html b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_39_porting_guide.html new file mode 100644 index 00000000000..9e24625f2f0 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_39_porting_guide.html @@ -0,0 +1,34 @@ + + + + + + +This guide covers migrating Eclipse 4.38 plug-ins to Eclipse 4.39.
+One of the goals of Eclipse 4.39 was to move Eclipse forward while remaining compatible + with previous versions to the greatest extent possible. That is, plug-ins written + against the Eclipse 4.38 APIs should continue to work in 4.39 in spite of any API changes.
+The key kinds of compatibility are API contract compatibility and binary compatibility. + API contract compatibility means that valid use of 4.38 APIs remains valid for + 4.39, so there is no need to revisit working code. Binary compatibility means + that the API method signatures, etc. did not change in ways that would cause + existing compiled ("binary") code to no longer link and run with the + new 4.39 libraries.
+While every effort was made to avoid breakage, there are a few areas of incompatibility or new + APIs that should be adopted by clients. + This document describes those areas and provides instructions for migrating 4.38 plug-ins to + 4.39.
+