class VersionManagement "Version Management"
    extends Modelica.Icons.ReleaseNotes;

    annotation (Documentation(info = "<html>\n<h4>Development branches</h4>\n<p>\nFurther development and maintenance of the Modelica Standard Library is performed with\ntwo branches on the public <a href=\"\">GitHub repository</a> of the Modelica Association.\n</p>\n\n<h5>Main development branch</h5>\n<p>\nName: \"master\"\n</p>\n\n<p>\nThis branch contains the actual development version, i.e., all bug fixes\nand new features.\nNew features must have been tested before including them.\nHowever, the exhaustive tests for a new version are (usually) not performed.\nThis version is usually only be used by the developers of the\nModelica Standard Library and is not utilized by Modelica users.\n</p>\n\n<h5>Maintenance branch</h5>\n<p>\nName: \"maint/3.2.3\"\n</p>\n\n<p>\nThis branch contains the released Modelica Standard Library version (e.g., v3.2.3)\nwhere all bug fixes since this release date are included (up to a new release,\nwhen becoming available; i.e., after a new release, the previous maintenance\nversions are no longer changed).\nThese bug fixes might be not yet tested with all test cases or with\nother Modelica libraries. The goal is that a vendor may take this version at\nany time for a new release of its software, in order to incorporate the latest\nbug fixes, without changing the version number of the Modelica Standard Library.\n</p>\n\n<h4>Contribution workflow</h4>\n<p>\nThe general <a href=\"\">contribution workflow</a> is usually as follows:\n</p>\n\n<ol>\n<li>Fork the repository to your account by\n   <a href=\"\">using the Fork button</a> of the GitHub repository site.</li>\n<li>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.</li>\n<li>Create a new topic branch and give it a meaningful name,\n   like, e.g., \"issue2161-fix-formula\".</li>\n<li>Do your code changes and commit them, one change per commit.\n   Single commits can be copied to other branches.\n   Multiple commits can be squashed into one, but splitting is difficult.</li>\n<li>Once you are done, push your topic branch to your forked repository.</li>\n<li>Go to the upstream <a href=\"\"></a> repository and submit a\n   <a href=\"\">Pull Request</a> (PR).\n   If the PR is related to a certain issue, reference it by its number like this: #2161.\n   Once a pull request is opened, you can discuss and\n   <a href=\"\">review</a>\n   the potential changes with collaborators and add follow-up commits before\n   the changes are merged into the repository.</li>\n<li>Update your branch with the requested changes. If necessary, merge the latest\n   \"master\" branch into your topic branch and solve all merge conflicts in your topic branch.</li>\n</ol>\n\n<p>\nThere are some special guidelines for changes to the maintenance branch.\n</p>\n\n<ul>\n<li> Every change to the maintenance branch has to get cherry-picked at the \"master\"\n         branch (see above), too. One exception are pure changes to the\n         \"versionBuild\" annotation as these have no meaning in the development trunk.</li>\n<li> Annotations \"version\" and \"versionDate\" must <u>not</u> be changed in a maintenance release.</li>\n<li> Since the version number can currently not be changed when releasing a new maintenance release\n     (also known as bug fix release) the Modelica Standard Library utilizes the \"versionBuild\" annotation\n     for this purpose. So should there be a new maintenance release in the maintenance branch then the\n     \"versionBuild\" number needs to be incremented by one. At the same time the \"dateModified\" field\n     needs to be updated.<br>\n     Example:\n         <pre>  annotation(version      = \"3.2.3\",\n             versionDate  = \"2019-01-23\",\n             versionBuild = 2,\n             dateModified = \"2019-01-23 07:40:19Z\",\n             revisionId   = \"$F&#8203;ormat:%h %ci$\")</pre>\n     The \"revisionId\" field is a special annotation to mark a properly released (maintenance) version from unreleased commits.<br>\n     Example:\n     <blockquote>\n        Running the export command \"<code>git archive -o v3.2.3</code>\" will\n        expand the above \"revisionId\" place holder to something like:\n        <pre>revisionId = \"c04e23a0d 2019-01-23 12:00:00 +0200$\"</pre>\n     </blockquote>\n     </li>\n</ul>\n\n<p>\nAs a recommendation, a valid bug fix to the maintenance branch may contain one or\nmore of the following changes.\n</p>\n\n<ul>\n<li> Correcting an equation.</li>\n<li> Correcting attributes quantity/unit/defaultUnit in a declaration.</li>\n<li> Improving/fixing the documentation.</li>\n<li> Introducing a new name in the public section of a class\n         (model, package, ...) or in any section of a partial class is <strong>not</strong> allowed.\n         Since otherwise, a user might use this new name and when storing its model\n         and loading it with an older build-version, an error would occur.</li>\n<li> Introducing a new name in the protected section of a non-partial\n         class should only be done if absolutely necessary to fix a bug.\n         The problem is that this might be non-backward compatible,\n         because a user might already extend from this class and already using the same name.</li>\n</ul>\n</html>"));
end VersionManagement;