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\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=\"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,\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=\"https://github.com/modelica/ModelicaStandardLibrary.git\">https://github.com/modelica/ModelicaStandardLibrary.git</a> repository and submit a\n <a href=\"https://help.github.com/articles/about-pull-requests/\">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=\"https://help.github.com/articles/about-pull-request-reviews/\">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​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 msl.zip 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;