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
