aas-core3 1.0.0
Manipulate, verify and de/serialize asset administration shells in C++.
Loading...
Searching...
No Matches
Contributing Guidelines

Issues

Please report bugs or feature requests by creating GitHub issues.

In Code

If you want to contribute in code, pull requests are welcome!

Please do create a new issue before you dive into coding. It can well be that we already started working on the feature, or that there are upstream or downstream complexities involved which you might not be aware of.

SDK Code Generation

The biggest part of the code has been automatically generated by aas-core-codegen. It probably makes most sense to change the generator rather than add new functionality. However, this needs to be decided on a case-by-case basis.

Building Tests

We introduce the CMake option BUILD_TESTS, so that the developer can decide whether the tests are built or not. Normal builds where the SDK is used as a dependency usually do not need to run tests, so BUILD_TESTS is set to OFF by default.

If you want to build the tests, you have to specify the option when you invoke CMake. For example, assuming you want to build the project in build/ directory, and you are in the root of the repository:

cmake \
-Bbuild/ \
-S. \
-DBUILD_TESTS=ON \
# ... and probably some more CMake lists options
$ dealing with the dependencies etc.

Pull Requests

Feature branches. We develop using the feature branches, see this section of the Git book.

If you are a member of the development team, create a feature branch directly within the repository.

Otherwise, if you are a non-member contributor, fork the repository and create the feature branch in your forked repository. See [this GitHub tuturial] for more guidance.

Branch Prefix. Please prefix the branch with your Github user name (e.g., mristin/Add-some-feature).

Commit Messages

The commit messages follow the guidelines from https://chris.beams.io/posts/git-commit:

  • Separate subject from body with a blank line,
  • Limit the subject line to 50 characters,
  • Capitalize the subject line,
  • Do not end the subject line with a period,
  • Use the imperative mood in the subject line,
  • Wrap the body at 72 characters, and
  • Use the body to explain what and why (instead of how).

Version Bumps

When you want to update the version, please undertake the following steps:

  • Update the version in CMakeLists.txt,
  • Update the version in vpckg.json,
  • Update the version in Doxyfile, and
  • Write an entry in doc/changelog.md.

We use SemVer for versioning. Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backward compatible manner, and
  • PATCH version when you make backward compatible bug fixes

Release candidates are suffixed with -alpha.1, -alpha.2 etc.

Dependency Upgrades

When you want to upgrade a dependency, make sure you update:

  • The version in vcpkg.json,
  • The required version in find_package(...) in CMakeLists.txt, and
  • The required version in aas_core3-config.cmake.