Skip to content

GitLab

Last edited by Hannes Kallwies
Page history

Development & Release Process

Development and release process

This page describes the process how changes are included to the sub-projects and released

Software Tools

New features

New features should be discussed with the core development team before they are implemented, so it can be decided whether the feature makes sense and how the details of the implementation should be.

Development

  • New features or bugfixes (initiated by a ticket in the issue tracker) are developed on a separate branch (e.g. feature_xy or bugfix_xy
  • When the desired changes are implemented, tested, style-compatible and working the performed changes are described in the file CHANGELOG which every sub-project contains in the root folder. Also the README and further documentation of the tool is adjusted to the changes.
  • A merge request to branch master is submitted
  • Another developer of the core-team checks,
    • Changelog: All changes are included in the Changelog
    • Functionality: The feature/bugfix works correct
    • LanSpec Compatability: The changes do not dissent the current version of the language specification
    • Quality Requirements: The quality requirements are fulfilled
    • Good Code: The code shows a good quality
  • If one of the upper points is not fulfilled the one who requested the merge is informed which issues still have to be fixed
  • Otherwise the developer who reviewed the merge request merges the new branch into the master branch
  • During the merge new version number is assigned (see section versioning). Several merge requests can be combined under a single new version number.
  • The commit is then marked with a tag representing the version number. This tag may not be moved anymore.
  • The new version of the binary is published on the website.

Versioning

The version numbers of the sub-projects have three parts (e.g. 1.4.3).

  • The first number is only incremented for major changes. An incremented first number indicates that the software is not compatible to earlier versions anymore.
  • The middle number is increased for new major features. Versions with the same first number have to be compatible to each other.
  • The last number is incremented for minor features or bugfixes.

Language Specification

Changes to the language specification should be the exception since they may have effect to any specification written in TeSSLa and every backend.

  • Requests for changes can be submitted by the issue tracker of this Gitlab page
  • Requested changes are discussed by the Institute of Software Engineering ans Programming Languages
  • After approval the changes are performed in the language specification repository by a member of the core developer team and all official software front- and backends are adjusted.
  • Another member of the core development team doublechecks the new document
  • The document gets a new version according to the versioning rules described in the language specification
  • The new version of the language specification is then published with the new binaries simultaneously

Core development team