Developing changes

How to develop and test software changes

To develop software you need to set up an Eclipse IDE with a Rodin installation as a target platform. In order for the API tools to check semantic versioning, you also need to install a Rodin platform as an API baseline. (See ..)

Update plug-ins and features version number

As soon as you change the source code the API tools will detect versioning errors. Reset the version number qualifier section of any changed plugin from .release to .qualifier and increment the version number according to the semantic versioning rules Semantic Versioning 2.0.0.

Given a version number MAJOR.MINOR.PATCH.qualifier/release: increment the MAJOR version when you make incompatible API changes, increment the MINOR version when you add functionality in a backwards-compatible manner, and increment the PATCH version when you make backwards-compatible bug fixes.

use the ".qualifier" label during testing. This will be automatically replaced with the date and time by Eclipse during build which enables the plugin to be re-installed when different versions are built When you are ready to publish the new version, change .qualifier to .release for the final published version.

The version for the features follows the same principle, taken into account the changes from the included plug-ins and features. I.e. if a major number has been increased for any plugin of the feature, increase the feature major version. Otherwise, if a minor number has increased, increase the feature minor number, otherwise justt increase the service patch number.

Develop and test the code

Develop and test the code by running from source against the target installation. Generally it is best to run in debug mode.

Update the Feature history

The release history keeps track of what changes to the plug-ins of a features from the previous release. The final release history together with the plug-in/feature version numbers will be published on different locations (README file, Rodin wiki, etc.). For now, we focus on update the release history as an entry in the feature.properties file of the corresponding feature.

Tips

• You can update the history as you go or leave it until you are ready to build the feature (or make a pull request into the main repository). If you are not completing the changes in tthe near future it might be best to updatte the history while you remember what you have done!
• The optimal way to find the changes to the plug-ins is to accumulate from the commit logs of the code (assuming that they have been carefully constructed).
• Sometimes it is necessary to compare the code or get a summary of the comparison of the code with the previous version (given by tag).
• It is a good practice to include any bug, feature requests, etc. closed in the release history (github actually forces you to include this information in commit message).