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=\"https://github.com/modelica/ModelicaStandardLibrary.git\">GitHub repository</a> of the Modelica Association.\n</p>\n<p>\nSince version 4.0.0 the Modelica Standard Library uses semantic versioning following the\nconvention:\n</p>\n <blockquote><strong><code>MAJOR.MINOR.BUGFIX</code></strong></blockquote>\n<p>\nThis provides a mechanism for maintaining releases and bug-fixes in a well defined way and is inspired\nby (but not identical to) <a href=\"https://semver.org\">https://semver.org</a>.\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/4.0.x\"\n</p>\n\n<p>\nThis branch contains the released Modelica Standard Library version (e.g., v4.0.0)\nwhere all bug-fixes since this release date are included\n(also consecutive <code>BUGFIX</code> versions 4.0.1, 4.0.2, etc.,\nup to when a new <code>MINOR</code> or <code>MAJOR</code> release becomes available;\ni.e., there will not be any further <code>BUGFIX</code> versions (i.e., 4.0.x) of a previous release).\nThese bug-fixes might not yet be 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.\n</p>\n\n<h4>Contribution workflow</h4>\n<p>\nThe general <a href=\"https://guides.github.com/activities/forking/\">contribution workflow</a> is usually as follows:\n</p>\n\n<ol>\n<li>Fork the repository to your account by\n <a href=\"https://help.github.com/articles/fork-a-repo/\">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, like, e.g., \"issue2161-fix-formula\".</li>\n<li>Do your code changes and commit them, one change per commit.<br>\n Single commits can be copied to other branches.<br>\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=\"https://github.com/modelica/ModelicaStandardLibrary.git\">https://github.com/modelica/ModelicaStandardLibrary.git</a> repository and submit a <a href=\"https://help.github.com/articles/about-pull-requests/\">Pull Request</a> (PR).\n <ul>\n <li>If the PR is related to a certain issue, reference it by its number like this: #2161.</li>\n <li>Once a pull request is opened, you can discuss and <a href=\"https://help.github.com/articles/about-pull-request-reviews/\">review</a> the potential changes with collaborators and add follow-up commits before the changes are merged into the repository.</li>\n <li>If you have not already signed the Modelica Association Contributor License Agreement (CLA) you need to do so one-time.<br>\n 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.</li>\n </ul></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.</li>\n<li> When a new <code>BUGFIX</code> release is due the annotations\n \"version\" and \"versionDate\" need to be updated.<br>\n Example:\n <blockquote><pre>\nannotation(version = \"4.0.1\",\n versionDate = \"2020-09-29\",\n dateModified = \"2020-09-29 07:40:19Z\",\n revisionId = \"$F​ormat:%h %ci$\")\n </pre></blockquote>\n The \"dateModfied\" is optional but might help identify the exact creation time of a release.\n The \"revisionId\" field is a special annotation to identify the exact commit that the released\n version represents.<br>\n Example:\n <blockquote>\n Running the export command \"<code>git archive -o msl.zip v4.0.0</code>\" will\n expand the above \"revisionId\" place holder to something like:\n <blockquote><pre>revisionId = \"c04e23a0d 2020-04-01 12:00:00 +0200$\"</pre></blockquote>\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 bug-fix 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;