VersionManagement

Maintenance of the Modelica Standard Library is performed with three branches on the subversion server of the Modelica Association (https://svn.modelica.org/projects/Modelica):

Released branch

Example: "/tags/v3.0.1/Modelica"

This branch contains the released Modelica versions (e.g., version 3.0.1), where all available test cases and compatibility checks with other Modelica libraries have been performed on the respective release. This version is usually shipped with a Modelica modeling and simulation environment and utilized by a Modelica user.

Development branch

Example: "/trunk/Modelica"

This branch contains the actual development version, i.e., all bug fixes and new features based on the last Modelica release. New features should 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

Example: "/branches/maintenance/3.0.1/Modelica"

This branch contains the released Modelica version (e.g., version 3.0.1) where all bug fixes since this release date are included (up to a new release, when becoming available; i.e., after a new release, the previous maintenance versions are no longer changed). These bug fixes might be not yet 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, without changing the version number of the Modelica Standard Library.

Incorporation of bug fixes (subversion "commit") shall be performed in the following way:

• One person is fixing the bug and another person is checking whether the fix is fine.
• It is up to the library developer, whether he opens a new branch for testing and then merges it with the "head" maintenance branch or not.
• Every change to the maintenance branch has to be done at the development branch (see above) as well.
• Every change to the maintenance branch requires introducing a description of the bug fix under Modelica.UsersGuide.ReleaseNotes.Version_<release-number>_BugFixes.
• Annotations "version" and "versionDate" must not be changed in a maintenance release.
• Every change to the maintenance branch requires changing the "versionBuild" number (incrementing it by one), as well as the "revisionId". The latter one is automatically done once a commit of file Modelica\package.mo is performed. Example:

    annotation(version      = "3.1",
               versionDate  = "2009-06-22",
               versionBuild = 3,
               dateModified = "2009-06-21 08:13:18Z",
               revisionId   = "$Id:: package.mo 3222 2009-12-18 08:53:50Z #$").

• If time does not permit, a vendor makes the bug fix in its local version and then has to include it in the maintenance version. It would be best to make these changes at a new branch in order to get a unique release number.

A valid "commit" 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 build-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.