gef-classic icon indicating copy to clipboard operation
gef-classic copied to clipboard

2024-12 release version

Open eobrienPilz opened this issue 11 months ago • 11 comments

Hi, It looks like the org.eclipse.gef bundle in eclipse 2024-12 release has the wrong version number. i.e. 3.20 instead of 3.22

Looking at the history of pom.xml it goes straight from 3.20 to 3.23.

https://github.com/eclipse-gef/gef-classic/commit/2d4774a6f2b5b94438c70f0183d3208095ec8c50#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8

eobrienPilz avatar Jan 15 '25 16:01 eobrienPilz

Hi, It looks like the org.eclipse.gef bundle in eclipse 2024-12 release has the wrong version number. i.e. 3.20 instead of 3.22

The version of the GEF bundle doesn't need to match the version of the GEF feature, which is what is defines the 3.22 release.

The 3.22 release: image

The 3.21 release: image

The 3.20 release: image

Note that the major version was increased due to changes to the API. It would've been just as valid to only increase the minor version between releases (or not at all), depending on the type of changes.

Looking at the history of pom.xml it goes straight from 3.20 to 3.23.

That's the version of the parent pom that was updated to match the GEF 3.23 release. But this is only relevant for the Maven/Tycho build and doesn't affect the release.

ptziegler avatar Jan 15 '25 16:01 ptziegler

Thanks for the information. Can you recommend a way, given a bundle to establish the git commit that it corresponds to ?

eobrienPilz avatar Jan 16 '25 09:01 eobrienPilz

The update site, e.g., https://download.eclipse.org/tools/gef/classic/release/3.22.0/index.html, as the commit that was head when that build was produced:

Image

And that commit for a release is tagged:

Image

merks avatar Jan 16 '25 09:01 merks

Thanks again, its really useful to have this information. If I understand correctly, additionally, It looks like I can get the gef version for a particular eclipse release from looking at the feature folder in the update site. i.e. https://download.eclipse.org/releases/2024-12/202412041000/features/

eobrienPilz avatar Jan 16 '25 11:01 eobrienPilz

If you are looking for a specific Eclipse Simrel release then your link is a good location. Otherwise you find all recent GEF classic releases here: https://download.eclipse.org/tools/gef/classic/release/

azoitl avatar Jan 16 '25 11:01 azoitl

Yes, I am pretty sure its the Eclipse Simrel release I need. We are working with an eclipse RCP product. I was trying to join the dots to understand the reasons for a code change. I think I have it now, knowing that I need to check the feature version and not the plugin version.

eobrienPilz avatar Jan 16 '25 12:01 eobrienPilz

Yes in that case it is much better to use the Simrel update site. We are doing something similar in 4diac IDE. From what you write it looks like that you are not yet using the target platform feature for your RCP developments. With that you can streamline the update process a lot.

azoitl avatar Jan 16 '25 19:01 azoitl

We are using the target platform for development and we periodically update the version that we use. While upgrading to 4.34 we had some compiler errors due to internal API usage. This is the commit that caused us issues.

https://github.com/eclipse-gef/gef-classic/commit/fb4a5ff2238e84ee79dbd0dc251aa1c00b62f316

Trying to locate this commit is what led to raising this issue. I can see now that this just a case of understanding the versioning.

eobrienPilz avatar Jan 17 '25 09:01 eobrienPilz

We are using the target platform for development and we periodically update the version that we use. While upgrading to 4.34 we had some compiler errors due to internal API usage. This is the commit that caused us issues.

The PaletteColorUtil constants? At least that's what we had to adapt in our application as well.

ptziegler avatar Jan 17 '25 10:01 ptziegler

Yes, these were giving errors after updating the target platform. I have seen that there are new utility methods available that can be called instead, which will allow us to patch up the offending piece of code. Unfortunately, there are still other internal methods that we are using in the same piece of our code. This runs the risk of breaking again in future if there are API changes. I may raise a separate issue or enhancement here next week once I understand better why we needed to use internal code and if there is an alternative implementation for us.

eobrienPilz avatar Jan 17 '25 12:01 eobrienPilz

This issue is stale because it has been open for 90 days with no activity.

github-actions[bot] avatar Apr 18 '25 02:04 github-actions[bot]

This issue was closed because it has been inactive for 180 days since being marked as stale.

github-actions[bot] avatar Oct 15 '25 02:10 github-actions[bot]