build: set version to 0.9.0 and change versioning scheme

[sebthom]

With this PR all feature/plugin versions are set to the same value 0.9.0 and the Version Bump section of CONTRIBUTING.md file is adjusted accordingly.

[mickaelistria]

To alleviate confusion among end-users regarding the effectively installed TM4E release and to ease the development process and troubleshooting, starting with version 0.9.0, individual TM4E features/plugins are no longer versioned independently (OSGi semantic versioning).

Note that forcing version bumps when there is no change leads to more artifacts being produced, hence more QA validation (for consumers who want to validate particular versions of dependencies) and more bandwidth and disk space consumed. For instance, if TM4E produce a bugfix release to 1 particular bundle, then it would result in all bundles being redownloaded with new versions. This is less green IT.

Note that the issue is not the OSGi version per se, the issue is more the project version which -in practice- is nothing technical nor useful, and is only there for "marketing" reasons. If one would keep OSGi versioning, and stop using project release versison (and use timestamps for example) then there would be no confusion while still having the (important enough to me) benefits of semantic versioning and reproducible version qualifier.

[sebthom]

Thanks for your comments. I understand your reasoning, but I disagree with the conclusion that OSGi versioning is the better choice in this context.

Being More Green

I feel the argument that OSGi versioning for TM4E is more environmentally friendly is a bit exaggerated, especially when working in an ecosystem where half-gigabyte-sized new Eclipse releases in multiple flavors are pushed out every 3 months. For TM4E, the core+ui only requires 650kb, and the language pack adds another 880kb. In fact, the current release of TM4E has become more environmentally friendly by removing the dependency on guava, which saved approximately 2.7MB. :tada: OSGi versioning also didn't save any disk space in our p2 repo, as each release folder contains copies of all plugins, irrespective if they had been changed or not. However, to truly make a meaningful environmental impact, I actually have a few suggestions:

• The Eclipse IDE project could re-introduce hot-fixes/fix backports for existing releases and reduce the release cadence to, for example, 6 months.
• Eclipse plugin projects should not over-eagerly build against or require the latest Eclipse platform release (as long as there are no technical reasons to do so). This would prevent people from having to download new full-blown Eclipse releases just to get newer fixes for issues in TM4E, LSP4E, WildWebDeveloper, etc. For TM4E I try to slow down this process, but there seem to be committers who like to bump the Eclipse platform requirement just because there are new Eclipse releases.

Release versions are not just marketing

Our change log is tied to the release version, and while we technically support version ranges we only test interoperability of plugin versions that are part of the same release. We haven't been doing good OSGi versioning anyways as we did not track or publish per-artifact changelogs and I don't believe anyone would be willing to do this work. Typically, the following scenario occurs:

1. Someone creates a PR.
2. the CI job fails because a plugin is missing a version bump.
3. (first-time committers get confused/surprised)
4. the PR contributor bumps the patch version just to get the build job to succeed
5. Another committer merges the PR without checking if only bumping the patch version bump was appropriate.
6. Later, other committers create feature PRs to the same plugins and forget to bump the individual plugin versions semantically correct, since the CI job succeeds.
7. At the end of the day, the "poor" guy creating the release (currently me :smiley:) has to go through all the plugins and their affecting commits to ensure that the plugin versions are bumped semantically correct.

Better for End Users

From an end-user perspective, the way we did OSGi versioning was not helpful. As said before, there are no changelogs per OSGi versioned plugin, and we do not documented which plugin versions belong to which release version. This lack of information has caused confusion for end users in the past. For example, there have been situations where end users experienced issues because some of the TM4E plugins did not get upgraded, and this was impossible for them to figure out. The TM4E issue list, and I believe as well as LSP4E and WildWebDeveloper, have had cases where people were confused about plugin versions not matching release versions.

Better for Plugin Developers

Having a single release version for all plugins also benefits plugin developers who depend on TM4E. It increases confidence and simplifies the upgrade process. Instead of going through the p2 repo to figure out which versions of each plugin were in which release, developers can simply use the TM4E release version number as baseline everywhere, regardless of whether they depend on tm4e.core, tm4e.registry, tm4e.ui, etc.