.Modelica.UsersGuide.ReleaseNotes.VersionManagement

Information

Development branches

Further development and maintenance of the Modelica Standard Library is performed with two branches on the public GitHub repository of the Modelica Association.

Since version 4.0.0 the Modelica Standard Library uses semantic versioning following the convention:

MAJOR.MINOR.BUGFIX

This provides a mechanism for maintaining releases and bug-fixes in a well defined way and is inspired by (but not identical to) https://semver.org.

Main development branch

Name: "master"

This branch contains the actual development version, i.e., all bug-fixes and new features. New features must have been tested before including them. However, the exhaustive tests for a new version are (usually) not performed. This version is usually only be used by the developers of the Modelica Standard Library and is not utilized by Modelica users.

Maintenance branch

Name: "maint/4.0.x"

This branch contains the released Modelica Standard Library version (e.g., v4.0.0) where all bug-fixes since this release date are included (also consecutive BUGFIX versions 4.0.1, 4.0.2, etc., up to when a new MINOR or MAJOR release becomes available; i.e., there will not be any further BUGFIX versions (i.e., 4.0.x) of a previous release). These bug-fixes might not yet be tested with all test cases or with other Modelica libraries. The goal is that a vendor may take this version at any time for a new release of its software, in order to incorporate the latest bug fixes.

Contribution workflow

The general contribution workflow is usually as follows:

1. Fork the repository to your account by using the Fork button of the GitHub repository site.
2. Clone the forked repository to your computer. Make sure to checkout the maintenance branch if the bug fix is going to get merged to the maintenance branch.
3. Create a new topic branch and give it a meaningful name, like, e.g., "issue2161-fix-formula".
4. Do your code changes and commit them, one change per commit.
   Single commits can be copied to other branches.
   Multiple commits can be squashed into one, but splitting is difficult.
5. Once you are done, push your topic branch to your forked repository.
6. Go to the upstream https://github.com/modelica/ModelicaStandardLibrary.git repository and submit a Pull Request (PR).
   • If the PR is related to a certain issue, reference it by its number like this: #2161.
   • Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before the changes are merged into the repository.
   • If you have not already signed the Modelica Association Contributor License Agreement (CLA) you need to do so one-time.
     You can sign the CLA electronically using the CLA Assistant service and your GitHub account. There is no need to scan and send any documents by mail.
7. Update your branch with the requested changes. If necessary, merge the latest "master" branch into your topic branch and solve all merge conflicts in your topic branch.

There are some special guidelines for changes to the maintenance branch.

• Every change to the maintenance branch has to get cherry-picked at the "master" branch (see above), too.
• When a new BUGFIX release is due the annotations "version" and "versionDate" need to be updated.
  Example:

  annotation(version      = "4.0.1",
             versionDate  = "2020-09-29",
             dateModified = "2020-09-29 07:40:19Z",
             revisionId   = "$F​ormat:%h %ci$")
           

  The "dateModfied" is optional but might help identify the exact creation time of a release. The "revisionId" field is a special annotation to identify the exact commit that the released version represents.
  Example:

  Running the export command "git archive -o msl.zip v4.0.0" will expand the above "revisionId" place holder to something like:

  revisionId = "c04e23a0d 2020-04-01 12:00:00 +0200$"

As a recommendation, a valid bug-fix to the maintenance branch may contain one or more of the following changes.

• Correcting an equation.
• Correcting attributes quantity/unit/defaultUnit in a declaration.
• Improving/fixing the documentation.
• Introducing a new name in the public section of a class (model, package, ...) or in any section of a partial class is not allowed. Since otherwise, a user might use this new name and when storing its model and loading it with an older bug-fix version, an error would occur.
• Introducing a new name in the protected section of a non-partial class should only be done if absolutely necessary to fix a bug. The problem is that this might be non-backward compatible, because a user might already extend from this class and already using the same name.