+ So far Eclipse did not change incompatibly between 4.35 and 4.36 in ways that affect + plug-ins. Plug-ins that ran on 4.35 should run on 4.36 without any problems. +
+ + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.36/recommended.html b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.36/recommended.html new file mode 100644 index 00000000000..e83c1d4af31 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.36/recommended.html @@ -0,0 +1,23 @@ + + + + + + + ++ This section describes changes that are required if you are trying to change + your 4.35 plug-in to adopt the 4.36 mechanisms and APIs. +
+ +This guide covers migrating Eclipse JDT 4.35 plug-ins to Eclipse JDT 4.36.
+One of the goals of Eclipse 4.36 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.35 APIs should continue to work in 4.36 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.35 APIs remains valid for + 4.36, 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.36 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.35 plug-ins to + 4.36.
++ Eclipse changed in incompatible ways between 4.35 and 4.36 in ways that affect + plug-ins. The following entries describe the areas that changed and provide + instructions for migrating 4.35 plug-ins to 4.36. Note that you only need to look + here if you are experiencing problems running your 4.35 plug-in on 4.36. +
++See also the list of deprecated API removals for this release. +
+ + + ++ The following platform-specific fragments have been merged into their respective host bundle: +
org.eclipse.core.resources.win32.win32.x86_64org.eclipse.core.filesystem.win32.x86_64org.eclipse.core.net.linuxorg.eclipse.core.net.win32+ All functionality formerly provided through these platform-specific fragments is now provided by the fragment's host bundle alone and no code change is required. + If any of the mentioned fragments is referenced in a PDE feature.xml or listed as content of a product definition it just has to be removed. +
+ + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.36/recommended.html b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.36/recommended.html new file mode 100644 index 00000000000..5e8d87e8e59 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.36/recommended.html @@ -0,0 +1,25 @@ + + + + + + + + +This section describes changes that are required if you are + trying to change your 4.35 plug-in to adopt the 4.36 mechanisms and + APIs.
+ + + + + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_36_porting_guide.html b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_36_porting_guide.html new file mode 100644 index 00000000000..bfecb16b15b --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_36_porting_guide.html @@ -0,0 +1,35 @@ + + + + + + + +This guide covers migrating Eclipse 4.35 plug-ins to Eclipse 4.36.
+One of the goals of Eclipse 4.36 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.35 APIs should continue to work in 4.36 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.35 APIs remains valid for + 4.36, 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.36 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.35 plug-ins to + 4.36.
+