Script 'mail_helper' called by obssrc Hello community, here is the log from the commit of package python-vcver for openSUSE:Factory checked in at 2022-10-14 15:41:20 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/python-vcver (Old) and /work/SRC/openSUSE:Factory/.python-vcver.new.2275 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-vcver" Fri Oct 14 15:41:20 2022 rev:2 rq:1010367 version:0.2.12 Changes: -------- --- /work/SRC/openSUSE:Factory/python-vcver/python-vcver.changes 2020-04-14 16:33:04.440185869 +0200 +++ /work/SRC/openSUSE:Factory/.python-vcver.new.2275/python-vcver.changes 2022-10-14 15:42:01.355866631 +0200 @@ -1,0 +2,6 @@ +Wed Oct 12 18:20:32 UTC 2022 - Yogalakshmi Arunachalam <yarunacha...@suse.com> + +- Update to version 0.2.12 + no upstream changelog + +------------------------------------------------------------------- Old: ---- vcver-0.2.11.tar.gz New: ---- vcver-0.2.12.tar.gz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ python-vcver.spec ++++++ --- /var/tmp/diff_new_pack.dKqooD/_old 2022-10-14 15:42:01.843867446 +0200 +++ /var/tmp/diff_new_pack.dKqooD/_new 2022-10-14 15:42:01.847867453 +0200 @@ -1,7 +1,7 @@ # # spec file for package python-vcver # -# Copyright (c) 2020 SUSE LLC +# Copyright (c) 2022 SUSE LLC # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed @@ -18,7 +18,7 @@ %{?!python_module:%define python_module() python-%{**} python3-%{**}} Name: python-vcver -Version: 0.2.11 +Version: 0.2.12 Release: 0 Summary: Provide package versions with version control data License: MIT ++++++ vcver-0.2.11.tar.gz -> vcver-0.2.12.tar.gz ++++++ diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/vcver-0.2.11/LICENSE new/vcver-0.2.12/LICENSE --- old/vcver-0.2.11/LICENSE 1970-01-01 01:00:00.000000000 +0100 +++ new/vcver-0.2.12/LICENSE 2021-08-10 07:11:30.000000000 +0200 @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2016 Yusuke Tsutsumi + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/vcver-0.2.11/PKG-INFO new/vcver-0.2.12/PKG-INFO --- old/vcver-0.2.11/PKG-INFO 2020-04-08 06:20:33.929924200 +0200 +++ new/vcver-0.2.12/PKG-INFO 2021-08-10 07:20:52.365692100 +0200 @@ -1,251 +1,11 @@ -Metadata-Version: 1.1 +Metadata-Version: 2.1 Name: vcver -Version: 0.2.11 +Version: 0.2.12 Summary: provide package versions with version control data. Home-page: https://github.com/toumorokoshi/vcver-python Author: Yusuke Tsutsumi Author-email: yus...@tsutsumi.io License: UNKNOWN -Description: ============ - vcver Python - ============ - - -------------- - What is vcver? - -------------- - - vcver is an approach for versioning that heavily relies on the version control - system of choice for determining version strings. - - There are two categories of version strings: - - develop versions, of the form: - - .. code-block:: - - {main_version}.dev{commit_count}+{branch}.{scm_change_id} - - With development branches, it is desired to not override versions published from - a blessed subset of "released" branches. As such, if the current branch is not a release - branch, a version of 0 is used instead of the main_version: - - .. code-block:: - - 0.dev{commit_count}+{branch}.{scm_change_id} - - and a release version, of the form: - - .. code-block:: - - {main_version} - - Each part is described as follows: - - * main_version is retrieved from the last tagged commit with a leading v (e.g. v1.0), - but is converted to a 0 if the branch is not a release branch. - * commit_count is the number of commits from main_version - * branch is the branch that the repository was built against, removing - characters that are incompatible with PEP440 (anything that is not alphanumeric or a dot) - * scm_change_id is a unique id in the form of version control, used to identify - the change that was used to build this version. - - For example, in a git repository, on a master branch with the most recent tag of - v1.1, the dev version would look something like: - - .. code-block:: - - 1.1.dev10+master.abc123 - - On a develop branch: - - .. code-block:: - - 0.dev13+develop.def456 - - And a release version: - - .. code-block:: - - 1.1 - - These are compatible with - `PEP440 <https://www.python.org/dev/peps/pep-0440/>`_. - - - ------- - Example - ------- - - Add a MANIFEST.in to your package, if you do not already have one. Then add the following: - - .. code-block:: - - include VERSION - - It's also recommended to ignore this file in your version control. - - Then, follow this pattern in your setup.py: - - .. code-block:: python - - - # OPTIONAL, but recommended: - # this block is useful for specifying when a build should - # use the 'release' version. it allows specifying a release version - # with an additional argument in the setup.py: - # $ python setup.py upload --release - import sys - is_release = False - if "--release" in sys.argv: - sys.argv.remove("--release") - is_release = True - - # OPTIONAL, but recommended: - # vcver writes a version file relative to the - # current working directory by default. - # It's recommended to provide it with your - # setup.py directory instead (in case someone - # runs your setup.py from a different directory) - base = os.path.dirname(os.path.abspath(__file__)) - - setup(name='aiohttp-transmute', - # add the following two lines, - # and do not specify a version. - setup_requires=["vcver"], - # vcver will only produce a release - # version if "is_release" is True. - vcver={ - "is_release": is_release, - "path": base, - # OPTIONAL ARGS - - # version_format overrides the standard version format - version_format="{main_version}.{commit_count}", - - # release_version_format overrides the release version format - release_version_format="{commit_count}", - - # scm_type: if you do not want autodetection of the SCM, you can - # specify it. - scm_type="git", - - # release_branch_regex: override the default release branch - # (default release branch depends on the SCM used.) - release_branch_regex="(master|hotfix|release)", - - # version_file: override the name of the version file. - version_file="GENERATED_VERSION" - }, - ... - ) - - Now your package will publish with a VC-based version! - - If you followed the full example, you can specify the release version by adding --release: - - .. code-block:: - - python setup.py upload --release - - ------------------- - FAQ / Other Details - ------------------- - - Why a dev and release version? - ============================== - - The dev and release versions have different goals: - - * dev: to provide as much information as possible to quickly identify - where the current version originated from in regard to version control. - * release: to provide a clear version that helps the consumer understand what changed. - - For most consumers, the number of commits since the last release, the - branch it was released against, or the build commit itself are - irrelevant. The consumer wants to know about the size of the change or type of changes, - and that can be done by the major / minor / patch versions specified - in the git tag, or the changelog. Adding version control information proves to be confusing with - that regard, providing multiple numbers that are not relevant to figuring out - the amount of change. - - Why zero out versions from non-release branches? - ================================================ - - Sometimes, a non-release version can be published accidentally, or it may be desired to publish - development versions side by side by versions published by release branches. In this situations, - ensuring that the release versions always take precedence over non-release version is valuable, to ensure - that development versions are not accidentally picked up by those expecting stable releases. - - If this behavior is not desired, custom version strings can be specified with "main_version" instead of "main_version". "main_version" is preserved regardless of the branch used. - - How to make sure others can consume your package - ================================================ - - If you followed the example, you already have this. - - Once vcver is called, a VERSION file is created in the current working - directory, which is typically the same directory as where the setup.py lives - (you can make it more accurate, see the example) - - vcver will attempt to find a VERSION file if the working directory is - not a version control repository. Make sure your package includes a - VERSION file by creating/modifying the - `MANIFEST.in <https://docs.python.org/2/distutils/sourcedist.html#the-manifest-in-template>`_: - - .. code-block:: - - include VERSION - - - Customizable Version Strings - ============================ - - Both the version format and release format is configurable, with the - arguments version_format and release_version_format, respectively. - - In addition to the values above, the following values are provided: - - * tag_version: the raw version of main_version, which does not zero - out for non-release branches. - - - - Pre-PEP440 Version - ================== - - Some (much older) versions of setuptools are unable to consume the dev version string, - due to the plus in the version string. - - If you need backwards compatibility and you would still like vc versioning, the - following format is recommended: - - .. code-block:: - - {main_version}.dev{commit_count}.{branch}.{scm_change_id} - - This can be changed by an argument into vcver: - - .. code-block:: python - - # in the setup call of setup.py - vcver={"version_format": "{main_version}.dev{commit_count}.{branch}.{scm_change_id}"} - - Compatibility with Semantic Versioning - ====================================== - - `Semantic versioning <http://semver.org/>`_ is a standard to provided a - meaning to the major, minor, and patch versions of a version - string. Compatibility with semver is possible if new major / minor - versions are tagged according the semver spec. - - -------------- - Special Thanks - -------------- - - - `Zillow <http://www.zillow.com/jobs/>`_, where this particular approach of SCM-based versioning was developed - - `Taylor McKay <https://github.com/tmckay>`_, who implemented the original Python version at Zillow - - `Mohammad Sarhan <https://github.com/sarhanm>`_, who designed and implemented the original Java version at Zillow, and has a public `gradle variant <https://github.com/sarhanm/gradle-versioner>`_ - Platform: UNKNOWN Classifier: Development Status :: 4 - Beta Classifier: Operating System :: MacOS @@ -257,3 +17,246 @@ Classifier: Programming Language :: Python :: 2.7 Classifier: Programming Language :: Python :: 3 Classifier: Programming Language :: Python :: 3.5 +License-File: LICENSE + +============ +vcver Python +============ + +-------------- +What is vcver? +-------------- + +vcver is an approach for versioning that heavily relies on the version control +system of choice for determining version strings. + +There are two categories of version strings: + +develop versions, of the form: + +.. code-block:: + + {main_version}.dev{commit_count}+{branch}.{scm_change_id} + +With development branches, it is desired to not override versions published from +a blessed subset of "released" branches. As such, if the current branch is not a release +branch, a version of 0 is used instead of the main_version: + +.. code-block:: + + 0.dev{commit_count}+{branch}.{scm_change_id} + +and a release version, of the form: + +.. code-block:: + + {main_version} + +Each part is described as follows: + +* main_version is retrieved from the last tagged commit with a leading v (e.g. v1.0), + but is converted to a 0 if the branch is not a release branch. +* commit_count is the number of commits from main_version +* branch is the branch that the repository was built against, removing + characters that are incompatible with PEP440 (anything that is not alphanumeric or a dot) +* scm_change_id is a unique id in the form of version control, used to identify + the change that was used to build this version. + +For example, in a git repository, on a master branch with the most recent tag of +v1.1, the dev version would look something like: + +.. code-block:: + + 1.1.dev10+master.abc123 + +On a develop branch: + +.. code-block:: + + 0.dev13+develop.def456 + +And a release version: + +.. code-block:: + + 1.1 + +These are compatible with +`PEP440 <https://www.python.org/dev/peps/pep-0440/>`_. + + +------- +Example +------- + +Add a MANIFEST.in to your package, if you do not already have one. Then add the following: + +.. code-block:: + + include VERSION + +It's also recommended to ignore this file in your version control. + +Then, follow this pattern in your setup.py: + +.. code-block:: python + + + # OPTIONAL, but recommended: + # this block is useful for specifying when a build should + # use the 'release' version. it allows specifying a release version + # with an additional argument in the setup.py: + # $ python setup.py upload --release + import sys + is_release = False + if "--release" in sys.argv: + sys.argv.remove("--release") + is_release = True + + # OPTIONAL, but recommended: + # vcver writes a version file relative to the + # current working directory by default. + # It's recommended to provide it with your + # setup.py directory instead (in case someone + # runs your setup.py from a different directory) + base = os.path.dirname(os.path.abspath(__file__)) + + setup(name='aiohttp-transmute', + # add the following two lines, + # and do not specify a version. + setup_requires=["vcver"], + # vcver will only produce a release + # version if "is_release" is True. + vcver={ + "is_release": is_release, + "path": base, + # OPTIONAL ARGS + + # version_format overrides the standard version format + version_format="{main_version}.{commit_count}", + + # release_version_format overrides the release version format + release_version_format="{commit_count}", + + # scm_type: if you do not want autodetection of the SCM, you can + # specify it. + scm_type="git", + + # release_branch_regex: override the default release branch + # (default release branch depends on the SCM used.) + release_branch_regex="(master|hotfix|release)", + + # version_file: override the name of the version file. + version_file="GENERATED_VERSION" + }, + ... + ) + +Now your package will publish with a VC-based version! + +If you followed the full example, you can specify the release version by adding --release: + +.. code-block:: + + python setup.py upload --release + +------------------- +FAQ / Other Details +------------------- + +Why a dev and release version? +============================== + +The dev and release versions have different goals: + +* dev: to provide as much information as possible to quickly identify + where the current version originated from in regard to version control. +* release: to provide a clear version that helps the consumer understand what changed. + +For most consumers, the number of commits since the last release, the +branch it was released against, or the build commit itself are +irrelevant. The consumer wants to know about the size of the change or type of changes, +and that can be done by the major / minor / patch versions specified +in the git tag, or the changelog. Adding version control information proves to be confusing with +that regard, providing multiple numbers that are not relevant to figuring out +the amount of change. + +Why zero out versions from non-release branches? +================================================ + +Sometimes, a non-release version can be published accidentally, or it may be desired to publish +development versions side by side by versions published by release branches. In this situations, +ensuring that the release versions always take precedence over non-release version is valuable, to ensure +that development versions are not accidentally picked up by those expecting stable releases. + +If this behavior is not desired, custom version strings can be specified with "main_version" instead of "main_version". "main_version" is preserved regardless of the branch used. + +How to make sure others can consume your package +================================================ + +If you followed the example, you already have this. + +Once vcver is called, a VERSION file is created in the current working +directory, which is typically the same directory as where the setup.py lives +(you can make it more accurate, see the example) + +vcver will attempt to find a VERSION file if the working directory is +not a version control repository. Make sure your package includes a +VERSION file by creating/modifying the +`MANIFEST.in <https://docs.python.org/2/distutils/sourcedist.html#the-manifest-in-template>`_: + +.. code-block:: + + include VERSION + + +Customizable Version Strings +============================ + +Both the version format and release format is configurable, with the +arguments version_format and release_version_format, respectively. + +In addition to the values above, the following values are provided: + +* tag_version: the raw version of main_version, which does not zero + out for non-release branches. + + + +Pre-PEP440 Version +================== + +Some (much older) versions of setuptools are unable to consume the dev version string, +due to the plus in the version string. + +If you need backwards compatibility and you would still like vc versioning, the +following format is recommended: + +.. code-block:: + + {main_version}.dev{commit_count}.{branch}.{scm_change_id} + + This can be changed by an argument into vcver: + +.. code-block:: python + + # in the setup call of setup.py + vcver={"version_format": "{main_version}.dev{commit_count}.{branch}.{scm_change_id}"} + +Compatibility with Semantic Versioning +====================================== + +`Semantic versioning <http://semver.org/>`_ is a standard to provided a +meaning to the major, minor, and patch versions of a version +string. Compatibility with semver is possible if new major / minor +versions are tagged according the semver spec. + +-------------- +Special Thanks +-------------- + +- `Zillow <http://www.zillow.com/jobs/>`_, where this particular approach of SCM-based versioning was developed +- `Taylor McKay <https://github.com/tmckay>`_, who implemented the original Python version at Zillow +- `Mohammad Sarhan <https://github.com/sarhanm>`_, who designed and implemented the original Java version at Zillow, and has a public `gradle variant <https://github.com/sarhanm/gradle-versioner>`_ + + diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/vcver-0.2.11/setup.py new/vcver-0.2.12/setup.py --- old/vcver-0.2.11/setup.py 2020-04-08 06:17:33.000000000 +0200 +++ new/vcver-0.2.12/setup.py 2021-08-10 07:19:37.000000000 +0200 @@ -12,7 +12,7 @@ setup( name="vcver", - version="0.2.11", + version="0.2.12", description="provide package versions with version control data.", long_description=open(README_PATH).read(), author="Yusuke Tsutsumi", diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/vcver-0.2.11/vcver.egg-info/PKG-INFO new/vcver-0.2.12/vcver.egg-info/PKG-INFO --- old/vcver-0.2.11/vcver.egg-info/PKG-INFO 2020-04-08 06:20:33.000000000 +0200 +++ new/vcver-0.2.12/vcver.egg-info/PKG-INFO 2021-08-10 07:20:52.000000000 +0200 @@ -1,251 +1,11 @@ -Metadata-Version: 1.1 +Metadata-Version: 2.1 Name: vcver -Version: 0.2.11 +Version: 0.2.12 Summary: provide package versions with version control data. Home-page: https://github.com/toumorokoshi/vcver-python Author: Yusuke Tsutsumi Author-email: yus...@tsutsumi.io License: UNKNOWN -Description: ============ - vcver Python - ============ - - -------------- - What is vcver? - -------------- - - vcver is an approach for versioning that heavily relies on the version control - system of choice for determining version strings. - - There are two categories of version strings: - - develop versions, of the form: - - .. code-block:: - - {main_version}.dev{commit_count}+{branch}.{scm_change_id} - - With development branches, it is desired to not override versions published from - a blessed subset of "released" branches. As such, if the current branch is not a release - branch, a version of 0 is used instead of the main_version: - - .. code-block:: - - 0.dev{commit_count}+{branch}.{scm_change_id} - - and a release version, of the form: - - .. code-block:: - - {main_version} - - Each part is described as follows: - - * main_version is retrieved from the last tagged commit with a leading v (e.g. v1.0), - but is converted to a 0 if the branch is not a release branch. - * commit_count is the number of commits from main_version - * branch is the branch that the repository was built against, removing - characters that are incompatible with PEP440 (anything that is not alphanumeric or a dot) - * scm_change_id is a unique id in the form of version control, used to identify - the change that was used to build this version. - - For example, in a git repository, on a master branch with the most recent tag of - v1.1, the dev version would look something like: - - .. code-block:: - - 1.1.dev10+master.abc123 - - On a develop branch: - - .. code-block:: - - 0.dev13+develop.def456 - - And a release version: - - .. code-block:: - - 1.1 - - These are compatible with - `PEP440 <https://www.python.org/dev/peps/pep-0440/>`_. - - - ------- - Example - ------- - - Add a MANIFEST.in to your package, if you do not already have one. Then add the following: - - .. code-block:: - - include VERSION - - It's also recommended to ignore this file in your version control. - - Then, follow this pattern in your setup.py: - - .. code-block:: python - - - # OPTIONAL, but recommended: - # this block is useful for specifying when a build should - # use the 'release' version. it allows specifying a release version - # with an additional argument in the setup.py: - # $ python setup.py upload --release - import sys - is_release = False - if "--release" in sys.argv: - sys.argv.remove("--release") - is_release = True - - # OPTIONAL, but recommended: - # vcver writes a version file relative to the - # current working directory by default. - # It's recommended to provide it with your - # setup.py directory instead (in case someone - # runs your setup.py from a different directory) - base = os.path.dirname(os.path.abspath(__file__)) - - setup(name='aiohttp-transmute', - # add the following two lines, - # and do not specify a version. - setup_requires=["vcver"], - # vcver will only produce a release - # version if "is_release" is True. - vcver={ - "is_release": is_release, - "path": base, - # OPTIONAL ARGS - - # version_format overrides the standard version format - version_format="{main_version}.{commit_count}", - - # release_version_format overrides the release version format - release_version_format="{commit_count}", - - # scm_type: if you do not want autodetection of the SCM, you can - # specify it. - scm_type="git", - - # release_branch_regex: override the default release branch - # (default release branch depends on the SCM used.) - release_branch_regex="(master|hotfix|release)", - - # version_file: override the name of the version file. - version_file="GENERATED_VERSION" - }, - ... - ) - - Now your package will publish with a VC-based version! - - If you followed the full example, you can specify the release version by adding --release: - - .. code-block:: - - python setup.py upload --release - - ------------------- - FAQ / Other Details - ------------------- - - Why a dev and release version? - ============================== - - The dev and release versions have different goals: - - * dev: to provide as much information as possible to quickly identify - where the current version originated from in regard to version control. - * release: to provide a clear version that helps the consumer understand what changed. - - For most consumers, the number of commits since the last release, the - branch it was released against, or the build commit itself are - irrelevant. The consumer wants to know about the size of the change or type of changes, - and that can be done by the major / minor / patch versions specified - in the git tag, or the changelog. Adding version control information proves to be confusing with - that regard, providing multiple numbers that are not relevant to figuring out - the amount of change. - - Why zero out versions from non-release branches? - ================================================ - - Sometimes, a non-release version can be published accidentally, or it may be desired to publish - development versions side by side by versions published by release branches. In this situations, - ensuring that the release versions always take precedence over non-release version is valuable, to ensure - that development versions are not accidentally picked up by those expecting stable releases. - - If this behavior is not desired, custom version strings can be specified with "main_version" instead of "main_version". "main_version" is preserved regardless of the branch used. - - How to make sure others can consume your package - ================================================ - - If you followed the example, you already have this. - - Once vcver is called, a VERSION file is created in the current working - directory, which is typically the same directory as where the setup.py lives - (you can make it more accurate, see the example) - - vcver will attempt to find a VERSION file if the working directory is - not a version control repository. Make sure your package includes a - VERSION file by creating/modifying the - `MANIFEST.in <https://docs.python.org/2/distutils/sourcedist.html#the-manifest-in-template>`_: - - .. code-block:: - - include VERSION - - - Customizable Version Strings - ============================ - - Both the version format and release format is configurable, with the - arguments version_format and release_version_format, respectively. - - In addition to the values above, the following values are provided: - - * tag_version: the raw version of main_version, which does not zero - out for non-release branches. - - - - Pre-PEP440 Version - ================== - - Some (much older) versions of setuptools are unable to consume the dev version string, - due to the plus in the version string. - - If you need backwards compatibility and you would still like vc versioning, the - following format is recommended: - - .. code-block:: - - {main_version}.dev{commit_count}.{branch}.{scm_change_id} - - This can be changed by an argument into vcver: - - .. code-block:: python - - # in the setup call of setup.py - vcver={"version_format": "{main_version}.dev{commit_count}.{branch}.{scm_change_id}"} - - Compatibility with Semantic Versioning - ====================================== - - `Semantic versioning <http://semver.org/>`_ is a standard to provided a - meaning to the major, minor, and patch versions of a version - string. Compatibility with semver is possible if new major / minor - versions are tagged according the semver spec. - - -------------- - Special Thanks - -------------- - - - `Zillow <http://www.zillow.com/jobs/>`_, where this particular approach of SCM-based versioning was developed - - `Taylor McKay <https://github.com/tmckay>`_, who implemented the original Python version at Zillow - - `Mohammad Sarhan <https://github.com/sarhanm>`_, who designed and implemented the original Java version at Zillow, and has a public `gradle variant <https://github.com/sarhanm/gradle-versioner>`_ - Platform: UNKNOWN Classifier: Development Status :: 4 - Beta Classifier: Operating System :: MacOS @@ -257,3 +17,246 @@ Classifier: Programming Language :: Python :: 2.7 Classifier: Programming Language :: Python :: 3 Classifier: Programming Language :: Python :: 3.5 +License-File: LICENSE + +============ +vcver Python +============ + +-------------- +What is vcver? +-------------- + +vcver is an approach for versioning that heavily relies on the version control +system of choice for determining version strings. + +There are two categories of version strings: + +develop versions, of the form: + +.. code-block:: + + {main_version}.dev{commit_count}+{branch}.{scm_change_id} + +With development branches, it is desired to not override versions published from +a blessed subset of "released" branches. As such, if the current branch is not a release +branch, a version of 0 is used instead of the main_version: + +.. code-block:: + + 0.dev{commit_count}+{branch}.{scm_change_id} + +and a release version, of the form: + +.. code-block:: + + {main_version} + +Each part is described as follows: + +* main_version is retrieved from the last tagged commit with a leading v (e.g. v1.0), + but is converted to a 0 if the branch is not a release branch. +* commit_count is the number of commits from main_version +* branch is the branch that the repository was built against, removing + characters that are incompatible with PEP440 (anything that is not alphanumeric or a dot) +* scm_change_id is a unique id in the form of version control, used to identify + the change that was used to build this version. + +For example, in a git repository, on a master branch with the most recent tag of +v1.1, the dev version would look something like: + +.. code-block:: + + 1.1.dev10+master.abc123 + +On a develop branch: + +.. code-block:: + + 0.dev13+develop.def456 + +And a release version: + +.. code-block:: + + 1.1 + +These are compatible with +`PEP440 <https://www.python.org/dev/peps/pep-0440/>`_. + + +------- +Example +------- + +Add a MANIFEST.in to your package, if you do not already have one. Then add the following: + +.. code-block:: + + include VERSION + +It's also recommended to ignore this file in your version control. + +Then, follow this pattern in your setup.py: + +.. code-block:: python + + + # OPTIONAL, but recommended: + # this block is useful for specifying when a build should + # use the 'release' version. it allows specifying a release version + # with an additional argument in the setup.py: + # $ python setup.py upload --release + import sys + is_release = False + if "--release" in sys.argv: + sys.argv.remove("--release") + is_release = True + + # OPTIONAL, but recommended: + # vcver writes a version file relative to the + # current working directory by default. + # It's recommended to provide it with your + # setup.py directory instead (in case someone + # runs your setup.py from a different directory) + base = os.path.dirname(os.path.abspath(__file__)) + + setup(name='aiohttp-transmute', + # add the following two lines, + # and do not specify a version. + setup_requires=["vcver"], + # vcver will only produce a release + # version if "is_release" is True. + vcver={ + "is_release": is_release, + "path": base, + # OPTIONAL ARGS + + # version_format overrides the standard version format + version_format="{main_version}.{commit_count}", + + # release_version_format overrides the release version format + release_version_format="{commit_count}", + + # scm_type: if you do not want autodetection of the SCM, you can + # specify it. + scm_type="git", + + # release_branch_regex: override the default release branch + # (default release branch depends on the SCM used.) + release_branch_regex="(master|hotfix|release)", + + # version_file: override the name of the version file. + version_file="GENERATED_VERSION" + }, + ... + ) + +Now your package will publish with a VC-based version! + +If you followed the full example, you can specify the release version by adding --release: + +.. code-block:: + + python setup.py upload --release + +------------------- +FAQ / Other Details +------------------- + +Why a dev and release version? +============================== + +The dev and release versions have different goals: + +* dev: to provide as much information as possible to quickly identify + where the current version originated from in regard to version control. +* release: to provide a clear version that helps the consumer understand what changed. + +For most consumers, the number of commits since the last release, the +branch it was released against, or the build commit itself are +irrelevant. The consumer wants to know about the size of the change or type of changes, +and that can be done by the major / minor / patch versions specified +in the git tag, or the changelog. Adding version control information proves to be confusing with +that regard, providing multiple numbers that are not relevant to figuring out +the amount of change. + +Why zero out versions from non-release branches? +================================================ + +Sometimes, a non-release version can be published accidentally, or it may be desired to publish +development versions side by side by versions published by release branches. In this situations, +ensuring that the release versions always take precedence over non-release version is valuable, to ensure +that development versions are not accidentally picked up by those expecting stable releases. + +If this behavior is not desired, custom version strings can be specified with "main_version" instead of "main_version". "main_version" is preserved regardless of the branch used. + +How to make sure others can consume your package +================================================ + +If you followed the example, you already have this. + +Once vcver is called, a VERSION file is created in the current working +directory, which is typically the same directory as where the setup.py lives +(you can make it more accurate, see the example) + +vcver will attempt to find a VERSION file if the working directory is +not a version control repository. Make sure your package includes a +VERSION file by creating/modifying the +`MANIFEST.in <https://docs.python.org/2/distutils/sourcedist.html#the-manifest-in-template>`_: + +.. code-block:: + + include VERSION + + +Customizable Version Strings +============================ + +Both the version format and release format is configurable, with the +arguments version_format and release_version_format, respectively. + +In addition to the values above, the following values are provided: + +* tag_version: the raw version of main_version, which does not zero + out for non-release branches. + + + +Pre-PEP440 Version +================== + +Some (much older) versions of setuptools are unable to consume the dev version string, +due to the plus in the version string. + +If you need backwards compatibility and you would still like vc versioning, the +following format is recommended: + +.. code-block:: + + {main_version}.dev{commit_count}.{branch}.{scm_change_id} + + This can be changed by an argument into vcver: + +.. code-block:: python + + # in the setup call of setup.py + vcver={"version_format": "{main_version}.dev{commit_count}.{branch}.{scm_change_id}"} + +Compatibility with Semantic Versioning +====================================== + +`Semantic versioning <http://semver.org/>`_ is a standard to provided a +meaning to the major, minor, and patch versions of a version +string. Compatibility with semver is possible if new major / minor +versions are tagged according the semver spec. + +-------------- +Special Thanks +-------------- + +- `Zillow <http://www.zillow.com/jobs/>`_, where this particular approach of SCM-based versioning was developed +- `Taylor McKay <https://github.com/tmckay>`_, who implemented the original Python version at Zillow +- `Mohammad Sarhan <https://github.com/sarhanm>`_, who designed and implemented the original Java version at Zillow, and has a public `gradle variant <https://github.com/sarhanm/gradle-versioner>`_ + + diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/vcver-0.2.11/vcver.egg-info/SOURCES.txt new/vcver-0.2.12/vcver.egg-info/SOURCES.txt --- old/vcver-0.2.11/vcver.egg-info/SOURCES.txt 2020-04-08 06:20:33.000000000 +0200 +++ new/vcver-0.2.12/vcver.egg-info/SOURCES.txt 2021-08-10 07:20:52.000000000 +0200 @@ -1,3 +1,4 @@ +LICENSE README.rst setup.py vcver/__init__.py