From c5892bd1d67d98adc0c7c6d387be9d540c2a3ca1 Mon Sep 17 00:00:00 2001 From: Suby S Surendran <117082823+subyssurendran666@users.noreply.github.com> Date: Wed, 30 Aug 2023 12:28:45 +0530 Subject: [PATCH] Migration guide for eclipse 4.29 (#1268) * Migration guide for eclipse 4.29 * incorporated the code review comments * Incorporated the code review comments * incorporated code review comments * Incorporated core review changes --- .../porting/4.29/faq.html | 20 ++++++++++ .../porting/4.29/incompatibilities.html | 14 +++++++ .../porting/4.29/recommended.html | 23 +++++++++++ .../porting/eclipse_4_29_porting_guide.html | 39 +++++++++++++++++++ .../topics_Porting.xml | 20 ++++++---- .../topics_Porting.xml | 20 ++++++---- 6 files changed, 122 insertions(+), 14 deletions(-) create mode 100644 eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.29/faq.html create mode 100644 eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.29/incompatibilities.html create mode 100644 eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.29/recommended.html create mode 100644 eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/eclipse_4_29_porting_guide.html diff --git a/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.29/faq.html b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.29/faq.html new file mode 100644 index 00000000000..b23b736886f --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.29/faq.html @@ -0,0 +1,20 @@ + + +
+ + + + ++ This section describes changes that are required if you are trying to change + your 4.28 plug-in to adopt the 4.29 mechanisms and APIs. +
+ +This guide covers migrating Eclipse JDT 4.28 plug-ins to Eclipse JDT 4.29.
+One of the goals of Eclipse 4.29 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.28 APIs should continue to work in 4.29 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.28 APIs remains valid for + 4.29, 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.29 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.28 plug-ins to + 4.29.
+