Add differentiation between development and release builds

[tobous]

There should be some way of differentiating between development and release builds to avoid confusion on the user side. Furthermore, this distinction would remove the possibility of running into internal incompatibilities when trying to use release builds with development builds (see #804).

Previously, we were using the suffix .DEVEL for this purpose. I would suggest to just use .DEV, but that is a matter of taste. (It would be even nicer to add the commit hash to guarantee compatibility between development builds, but that would require git functionality that may not be present when building, so I am not sure whether this is doable.)

Furthermore, the previous solution (before the move to semantic versioning) was to always have the ".DEVEL" qualifier committed in the git repo, only remove it temporarily for releases, and then add it back (and increase the current release number).

A better solution (in my opinion) would be to patch the version as part of the build process. This could by done by adding a .DEV modifier to the version by default unless a specific argument is provided specifying that the process should create a release build.
This would lead to the build always creating development builds unless specified otherwise and would remove the hassle of having to manage "DEV" status in the git repo.

I know that this is possible for IntelliJ (but would require moving the process of setting the version number from the plugin.xml to the build.gradle file).

@m273d15 Do you know whether something like this also possible for building Eclipse plugins?

Also, for the Saros Server, we would have to patch SarosServer.java as it contains the version number.

[m273d15]

In order to use a consistent version number in the metafiles (as the Manifest and plugin.xml which provide additional information for the IDEs) as well as in our internal version handling (during the compatibility check) we need some adjustments:

• Server - There are no metafiles, but it uses the constant string SAROS_VERSION = "15.0.0" in SarosServer.java:17 for the internal handing.
  TODO:
  • provide a MANIFEST.MF (the common solution for providing a jar version) with version number
  • parse the MANIFEST.MF and use its version number
  • We have to be careful the version in SAROS_VERSION is not the version of the server. It is the eclipse version that has to be used to connect to the server.
  • Set the version in the build process
• Eclipse - Meta-information are located in feature.xml (for the update site) and MANIFEST.MF. The feature.xml is only required for creating an update site. Therefore just updating the MANIFEST.MF is good enough in my opinion (manually adjusting the version for a release is acceptable). The internal handling determines the version based on the bundle number which is the version specified in the MANIFEST.MF.
  TODO:
  • Set the version in the build process (same mechanism as in the server)

[tobous]

Actually, when we provide a manifest for the server, we probably don't need the SAROS_VERSION specified in SarosServer.java as I would assume that the server is always compatible with the Saros/E release with the same revision.

[m273d15]

Maybe my explanation was not very clear:

We have to be careful the version in SAROS_VERSION is not the version of the server. It is the eclipse version that has to be used to connect to the server.

Sure, we don't need the SAROS_VERSION string after introducing a version into the manifest, but in the future, the server should be compatible with IntelliJ as well as Eclipse (and probably further implementations). The solution in the future could be: Identify the compatible components with the used core version. However, in the near future, we will live with the workaround that the Eclipse version is only supported and I would like to differentiate between the Saros server version (I would assume the version is currently something like 0.1/1.0) and the supported Saros/E version.

To cut a long story short, I would use the manifest version tag "version-number" as the server version and add a custom attribute as "saros-e-version" for the other version.

[m273d15]

@tobous We alredy implemented a similar solution for our nightly builds. What do you think is missing to re-use this approach to fix this issue?

[tobous]

@tobous We alredy implemented a similar solution for our nightly builds. What do you think is missing to re-use this approach to fix this issue?

We can use basically the same logic. But, as mentioned in the issue, local builds might not always have access to a git instance, meaning we can't use the latest commit short-hash as the qualifier. So we probably have to simply go with dev (we could include the date, but I am not sure whether that really servers a purpose and isn't just annoying to use). This reduces the effect of such a modifier by quite a bit as it no longer prevents mixing dev builds, but it would still prevent mixing dev builds with release builds.

This all is based on us actually using the qualifier for compatibility checks, which we currently don't do. So that would also be an important change.

[m273d15]

local builds might not always have access to a git instance

This is only the case if someone would download the project as zip.
However, we could use the git version plugin:
It uses jgit as a dependency and does not require a preinstalled cli tool.

This all is based on us actually using the qualifier for compatibility checks, which we currently don't do. So that would also be an important change.

Should be easy to adjust in the new VersionManager

[tobous]

This is only the case if someone would download the project as zip.
However, we could use the git version plugin:
It uses jgit as a dependency and does not require a preinstalled cli tool.

Yes, but the git commit hash has far less of a significance when building locally as we don't know whether the local repo is in a clean state. So I wouldn't invest too much time to get it to work. But if it is easy to set up and also still works in cases where there is no local git repo (i.e. the code was downloaded as a zip), using the plugin sounds like a good solution for dev builds to me.

[m273d15]

I created a small test commit and found the following TODOs:

• Add a workaround if the .git directory is missing (see here). This is simple but ugly (add the plugin to the project (with apply false) and apply the plugin in a try-catch block).
• Copy meta-files to "build" dir before changing the version. Otherwise, each build (with a new commit) leads to changes (tracked by git).
• Improve the logic of changing the versions. Currently, overwriting the version once is possible, but
  not a second time (the feature was introduced for CI and the idea was not to overwrite qualifiers that are defined by a user)

[tobous]

• Copy meta-files to "build" dir before changing the version. Otherwise, each build (with a new commit) leads to changes (tracked by git).

This only applies to Saros/E builds?

• Improve the logic of changing the versions. Currently, overwriting the version once is possible, but
  not a second time (the feature was introduced for CI and the idea was not to overwrite qualifiers that are defined by a user)

Which version? Only Saros/E, both versions, only Saros/I (,the core)?