bugpipe 3.0.1__tar.gz → 3.0.2__tar.gz

{bugpipe-3.0.1 → bugpipe-3.0.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: bugpipe
-Version: 3.0.1
+Version: 3.0.2
 Summary: Unofficial Python client for Buganizer; the Google Issue Tracking system
 Keywords: buganizer,google-issue-tracker,issue-tracker,bug-tracker,bug-bounty,vulnerability,security,chromium,cve,vrp,google
 Author: Ritchie Mwewa

{bugpipe-3.0.1 → bugpipe-3.0.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "bugpipe"
-version = "3.0.1"
+version = "3.0.2"
 description = "Unofficial Python client for Buganizer; the Google Issue Tracking system"
 readme = "README.md"
 license = "MIT"

{bugpipe-3.0.1 → bugpipe-3.0.2}/src/bugpipe/cli/update_checker.py

@@ -93,7 +93,7 @@ def standard_release(version: str) -> bool:
 
 
 def check(
-    package_name: str = "buganize",
+    package_name: str = __pkg__,
     package_version: str = __version__,
     status: Status | None = None,
 ):
@@ -162,34 +162,6 @@ def parse_version(string: str) -> tuple[str, ...]:
     """
     Convert a version string to a chronologically-sortable key.
 
-    This is a rough cross between distutils' StrictVersion and LooseVersion;
-    if you give it versions that would work with StrictVersion, then it behaves
-    the same; otherwise it acts like a slightly-smarter LooseVersion. It is
-    *possible* to create pathological version coding schemes that will fool
-    this parser, but they should be very rare in practice.
-
-    The returned value will be a tuple of strings.  Numeric portions of the
-    version are padded to 8 digits so they will compare numerically, but
-    without relying on how numbers compare relative to strings.  Dots are
-    dropped, but dashes are retained.  Trailing zeros between alpha segments
-    or dashes are suppressed, so that e.g. "2.4.0" is considered the same as
-    "2.4". Alphanumeric parts are lower-cased.
-
-    The algorithm assumes that strings like "-" and any alpha string that
-    alphabetically follows "final"  represents a "patch level".  So, "2.4-1"
-    is assumed to be a branch or patch of "2.4", and therefore "2.4.1" is
-    considered newer than "2.4-1", which in turn is newer than "2.4".
-
-    Strings like "a", "b", "c", "alpha", "beta", "candidate" and so on (that
-    come before "final" alphabetically) are assumed to be pre-release versions,
-    so that the version "2.4" is considered newer than "2.4a1".
-
-    Finally, to handle miscellaneous cases, the strings "pre", "preview", and
-    "rc" are treated as if they were "c", i.e. as though they were release
-    candidates, and therefore are not as new as a version string that does not
-    contain them, and "dev" is replaced with an '@' so that it sorts lower than
-    any other pre-release tag.
-
     :param string: The version string to parse.
     :return: A tuple of strings suitable for comparison.
     """