0.8.1

[mickaelistria]

What's Changed

• build(deps): bump tycho-version from 3.0.5 to 4.0.0 by @dependabot in build(deps): bump tycho-version from 3.0.5 to 4.0.0 #569
• build(deps): bump org.junit.jupiter:junit-jupiter-engine from 5.9.3 to 5.10.0 by @dependabot in build(deps): bump org.junit.jupiter:junit-jupiter-engine from 5.9.3 to 5.10.0 #571
• build(deps): bump tycho-version from 4.0.0 to 4.0.1 by @dependabot in build(deps): bump tycho-version from 4.0.0 to 4.0.1 #574
• build(deps): Build against new Orbit and Platform by @akurtakov in build(deps): Build against new Orbit and Platform #576
• ci(deps): bump srvaroa/labeler from 1.6.0 to 1.6.1 by @dependabot in ci(deps): bump srvaroa/labeler from 1.6.0 to 1.6.1 #579
• fix: Include guava in p2 repository by @akurtakov in fix: Include guava in p2 repository #581
• fix: Content Type selector of Language Configuration Wizard is empty Can't add a Language Configuration #582 by @sebthom in fix: Content Type selector of Language Configuration Wizard is empty #582 #583
• build(deps): bump snakeyaml from 2.0 to 2.1 by @sebthom in build(deps): bump snakeyaml from 2.0 to 2.1 #584
• build: Releng fixes by @akurtakov in build: Releng fixes #587
• build(deps): bump tycho-version from 4.0.1 to 4.0.2 by @dependabot in build(deps): bump tycho-version from 4.0.1 to 4.0.2 #586

Full Changelog: 0.8.0...0.8.1

---

This discussion was created from the release 0.8.1.

[iloveeclipse]

Don't get me wrong, but I'm bit confused where 0.8.1 number is coming from? None of the bundles / features has 0.8.1 version in it:

• https://download.eclipse.org/tm4e/releases/0.8.1/features/
• https://download.eclipse.org/tm4e/releases/0.8.1/plugins/

Is this a bug in version numbering of a feature or do I miss something?
Reason for asking: coming from the project where 0.8.1 is marked as "latest", user installs tm4e and sees only 0.6.1 not later versions.

[sebthom]

a tm4e release contains multiple features that are versioned independently following semver. so yes, the tm4e release version is only a logical number not embedded in the artifacts and thus not visible when installed in eclipse. lsp4e follows the same approach.

your question has come up several times already, so from an end user perspective the current approach does not seem ideal and apparently leads to confusion. I personally would prefer to do it like in maven multi module projects and simply set the release/feature/plugin versions to the same value on each release. I feel that trying to define/maintain downward/upward compatibility constraints between the tm4e plugins of different releases is just an academic exercise and provides no real-world value.

@mickaelistria since you are a strong proponent of the current versioning approach, maybe you want to chim in.

[mickaelistria]

Semantic versioning and reproducible versions&qualifiers are the way things are done in Platform bundles too. The goal of semantic versioning is to inform consumers about compatibility.
Reproducible versions&qualifiers minimize the amount of bundles that are produced, with the goal of 1. reducing need of QE (a bundle that was validated 2 years ago and wasn't touched for 2 years doesn't need to be revalidated, as it's unchanged) and the need to deliver/download new versions with no payload and thus save bandwidth. This is quite important in real-world for those who care about security or green IT.

But, all that said is about bundles, I agree it would be good if the feature shows the project version.