Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bumprelease functionality #382

Open
nishant-kumar47 opened this issue Mar 10, 2022 · 6 comments
Open

bumprelease functionality #382

nishant-kumar47 opened this issue Mar 10, 2022 · 6 comments
Assignees

Comments

@nishant-kumar47
Copy link

nishant-kumar47 commented Mar 10, 2022

Hi Team,
I am not sure how bumprelease feature works. Does it read "--breaking" from git log and detemines that it has to bump the release to next major release or its more like passing it via cli "bumprelease --breaking".
secondly. if my tags are like v1.0.1 and if I do bumprelease --version. it fails.

(base) [root@6ee061279253 legobricks]# bumpversion --breaking
Checking version bump for breaking release.
This is NOT a clean checkout. You are on a tag or you have local changes.
Are you sure you want to continue? (y/N)? y
Last tag: v1.3.1
Current version: 1.3.1
Traceback (most recent call last):
  File "/opt/conda/bin/bumpversion", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 152, in main
    bumpversion.run()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/baserelease.py", line 421, in run
    self.prepare()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 60, in prepare
    self._grab_version(initial=True)
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 109, in _grab_version
    if parse_version(minimum_version) <= parse_version(
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/__init__.py", line 128, in parse_version
    return packaging.version.Version(v)
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py", line 274, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

When current tag is v1.3.1 and version is setup.py is 1.3.1.. Should bumpversion --breaking, increase it to 2.0.0 instead of failing

Last tag: v1.3.1
Current version: 1.3.1

and we do tagging as v1.0.1 in our project, so what should exactly go in setup.cfg to take care of this format
tag-format = v'{version}' or something else

@mauritsvanrees
Copy link
Member

Hi Team, I am not sure how bumprelease feature works. Does it read "--breaking" from git log and detemines that it has to bump the release to next major release or its more like passing it via cli "bumprelease --breaking".

You pass it as option on the command line.

Theoretically we could teach it to look in your CHANGES.rst or when you use towncrier look for files like news/123.breaking, but currently this does not happen. So you should look yourself in the recent changes (optionally with the zest.releaser commands lasttaglog or lasttagdiff) and make a judgement call: should it be a breaking release, feature release, or bugfix release.

secondly. if my tags are like v1.0.1 and if I do bumprelease --version. it fails.

(base) [root@6ee061279253 legobricks]# bumpversion --breaking
Checking version bump for breaking release.
This is NOT a clean checkout. You are on a tag or you have local changes.
Are you sure you want to continue? (y/N)? y

You are calling bumpversion from a tag. You should call it from a branch instead. We will make changes, and this needs to land in a commit on a branch.
I don't think this is what causes the problem though.

Last tag: v1.3.1
Current version: 1.3.1
Traceback (most recent call last):
  File "/opt/conda/bin/bumpversion", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 152, in main
    bumpversion.run()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/baserelease.py", line 421, in run
    self.prepare()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 60, in prepare
    self._grab_version(initial=True)
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 109, in _grab_version
    if parse_version(minimum_version) <= parse_version(
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/__init__.py", line 128, in parse_version
    return packaging.version.Version(v)
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py", line 274, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

It looks like somehow a wrong version ends up in here. We use this code to parse a version, which looks like it works both with and without a v in front:

>>> from pkg_resources import parse_version
>>> parse_version("v1.2.3")
<Version('1.2.3')>
>>> parse_version("1.2.3")
<Version('1.2.3')>

It would fail when we somehow pass None:

>>> parse_version(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/maurits/zest.releaser/lib/python3.9/site-packages/pkg_resources/__init__.py", line 120, in parse_version
    return packaging.version.Version(v)
  File "/Users/maurits/zest.releaser/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py", line 264, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

Are you familiar with pdb? Can you put a breakpoint in bumpversion.py before line 109 where it breaks, and look around?

Otherwise, tell bumpversion to print debugging info:

bumpversion --breaking --verbose

When current tag is v1.3.1 and version is setup.py is 1.3.1.. Should bumpversion --breaking, increase it to 2.0.0 instead of failing

It should increase it to 2.0.0.

and we do tagging as v1.0.1 in our project, so what should exactly go in setup.cfg to take care of this format tag-format = v'{version}' or something else

Without the quotes. In setup.cfg:

[zest.releaser]
tag-format = v{version}

But I played around a bit in a test repository, also with the v in front of the tag (which I am not used to), and could not reproduce the problem. It might depend on the version of Python and setuptools.

Oh, and the version of zest.releaser of course. Which version are you using? Latest alpha is 7.0.0a2, which I used for testing now. Latest stable is 6.22.2. Both should work though.

@nishant-kumar47
Copy link
Author

Hi Team, I am not sure how bumprelease feature works. Does it read "--breaking" from git log and detemines that it has to bump the release to next major release or its more like passing it via cli "bumprelease --breaking".

You pass it as option on the command line.

Theoretically we could teach it to look in your CHANGES.rst or when you use towncrier look for files like news/123.breaking, but currently this does not happen. So you should look yourself in the recent changes (optionally with the zest.releaser commands lasttaglog or lasttagdiff) and make a judgement call: should it be a breaking release, feature release, or bugfix release.

secondly. if my tags are like v1.0.1 and if I do bumprelease --version. it fails.

(base) [root@6ee061279253 legobricks]# bumpversion --breaking
Checking version bump for breaking release.
This is NOT a clean checkout. You are on a tag or you have local changes.
Are you sure you want to continue? (y/N)? y

You are calling bumpversion from a tag. You should call it from a branch instead. We will make changes, and this needs to land in a commit on a branch. I don't think this is what causes the problem though.

Last tag: v1.3.1
Current version: 1.3.1
Traceback (most recent call last):
  File "/opt/conda/bin/bumpversion", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 152, in main
    bumpversion.run()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/baserelease.py", line 421, in run
    self.prepare()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 60, in prepare
    self._grab_version(initial=True)
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 109, in _grab_version
    if parse_version(minimum_version) <= parse_version(
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/__init__.py", line 128, in parse_version
    return packaging.version.Version(v)
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py", line 274, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

It looks like somehow a wrong version ends up in here. We use this code to parse a version, which looks like it works both with and without a v in front:

>>> from pkg_resources import parse_version
>>> parse_version("v1.2.3")
<Version('1.2.3')>
>>> parse_version("1.2.3")
<Version('1.2.3')>

It would fail when we somehow pass None:

>>> parse_version(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/maurits/zest.releaser/lib/python3.9/site-packages/pkg_resources/__init__.py", line 120, in parse_version
    return packaging.version.Version(v)
  File "/Users/maurits/zest.releaser/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py", line 264, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

Are you familiar with pdb? Can you put a breakpoint in bumpversion.py before line 109 where it breaks, and look around?

I actually set a print command there at 108. and its doent print the parse_version. Seems like prse_version is blank somehow

            print ("*"*10)
            print (parse_version)
            if parse_version(minimum_version) <= parse_version(
                    utils.cleanup_version(original_version)):
                print("No version bump needed.")

Otherwise, tell bumpversion to print debugging info:

bumpversion --breaking --verbose

Verbose output:

Verbose output

DEBUG: Running command: '/opt/conda/bin/python3.9 setup.py --version'
DEBUG: Running command: 'git tag'
DEBUG: Available tags: '1.3.2, v0.0.2, v0.1.0, v0.2.0, v0.2.1, v0.2.2, v1.0.0, v1.0.1, v1.0.2, v1.1.0, v1.1.1, v1.1.2, v1.2.0, v1.2.1, v1.2.2, v1.2.3, v1.3.0, v1.3.1'
DEBUG: Found exact match: v1.3.1
Last tag: v1.3.1
Current version: 1.3.1
**********
<function parse_version at 0x7f09b3494160>
Traceback (most recent call last):
  File "/opt/conda/bin/bumpversion", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 154, in main
    bumpversion.run()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/baserelease.py", line 421, in run
    self.prepare()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 60, in prepare
    self._grab_version(initial=True)
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 111, in _grab_version
    if parse_version(minimum_version) <= parse_version(
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/__init__.py", line 128, in parse_version
    return packaging.version.Version(v)
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py", line 274, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object
(base) [root@6ee061279253 legobricks]# git status
On branch master
Your branch is up to date with 'origin/master'.

When current tag is v1.3.1 and version is setup.py is 1.3.1.. Should bumpversion --breaking, increase it to 2.0.0 instead of failing

It should increase it to 2.0.0.

and we do tagging as v1.0.1 in our project, so what should exactly go in setup.cfg to take care of this format tag-format = v'{version}' or something else

Without the quotes. In setup.cfg:

[zest.releaser]
tag-format = v{version}

But I played around a bit in a test repository, also with the v in front of the tag (which I am not used to), and could not reproduce the problem. It might depend on the version of Python and setuptools.

Oh, and the version of zest.releaser of course. Which version are you using? Latest alpha is 7.0.0a2, which I used for testing now. Latest stable is 6.22.2. Both should work though.

@nishant-kumar47
Copy link
Author

Verbose output


DEBUG: Running command: '/opt/conda/bin/python3.9 setup.py --version'
DEBUG: Running command: 'git tag'
DEBUG: Available tags: '1.3.2, v0.0.2, v0.1.0, v0.2.0, v0.2.1, v0.2.2, v1.0.0, v1.0.1, v1.0.2, v1.1.0, v1.1.1, v1.1.2, v1.2.0, v1.2.1, v1.2.2, v1.2.3, v1.3.0, v1.3.1'
DEBUG: Found exact match: v1.3.1
Last tag: v1.3.1
Current version: 1.3.1
**********
<function parse_version at 0x7f09b3494160>
Traceback (most recent call last):
  File "/opt/conda/bin/bumpversion", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 154, in main
    bumpversion.run()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/baserelease.py", line 421, in run
    self.prepare()
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 60, in prepare
    self._grab_version(initial=True)
  File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 111, in _grab_version
    if parse_version(minimum_version) <= parse_version(
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/__init__.py", line 128, in parse_version
    return packaging.version.Version(v)
  File "/opt/conda/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py", line 274, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object
(base) [root@6ee061279253 legobricks]# git status
On branch master
Your branch is up to date with 'origin/master'.

@mauritsvanrees
Copy link
Member

I actually set a print command there at 108. and its doent print the parse_version. Seems like prse_version is blank somehow

You are printing the function, not the outcome of the function. Can you print the following instead?

import zest.releaser
print(zest.releaser.__version__)
print(f"Last tag: '{last_tag_version}'")
print(f"Current version: '{original_version}'")
print(type(last_tag_version))
print(type(original_version))
print(minimum_version)
print(utils.cleanup_version(original_version))
print(parse_version(minimum_version))
print(parse_version(utils.cleanup_version(original_version)))

I expect one of the last two lines to fail.

@nishant-kumar47
Copy link
Author

6.22.2
Last tag: 'v1.4.0'
Current version: '1.4.0'
type(last_tag_version): '<class 'str'>'
type(original_version): '<class 'str'>'
minimum_version: 'None'
utils.cleanup_version(original_version): '1.4.0'
parse_version(utils.cleanup_version(original_version)): '1.4.0'

print(parse_version(minimum_version)) produces the below error as minimum_version(seen above) in NONE

File "/opt/conda/bin/bumpversion", line 8, in
sys.exit(main())
File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 164, in main
bumpversion.run()
File "/opt/conda/lib/python3.9/site-packages/zest/releaser/baserelease.py", line 421, in run
self.prepare()
File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 60, in prepare
self._grab_version(initial=True)
File "/opt/conda/lib/python3.9/site-packages/zest/releaser/bumpversion.py", line 118, in _grab_version
print(parse_version(minimum_version))
File "/opt/conda/lib/python3.9/site-packages/pkg_resources/init.py", line 128, in parse_version
return packaging.version.Version(v)
File "/opt/conda/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py", line 274, in init
match = self._regex.search(version)
TypeError: expected string or bytes-like object

@mauritsvanrees
Copy link
Member

So the problem is with calling utils.suggest_version.

>>> from zest.releaser.utils import suggest_version
>>> suggest_version("v1.4.0")
'v1.4.1'
>>> suggest_version("v1.4.0", feature=True)
'v1.5.0'
>>> suggest_version("v1.4.0", breaking=True)

When called with breaking=True, the code tries to do int("v1") and this fails, so it returns None, which is used as minimum_version.

I can change suggest_version to remove the v in front of the version before handling it further. That would work for tag-format = v{version} which you have, but still fail for something like tag-format = release-{version}. Supporting arbitrary tags could be tricky, although I could try to at least prevent the above traceback.
I guess 95 percent simply use tag 1.2.3, and of the remaining 5 percent 95 percent uses v1.2.3. So fixing it for the v case would mean it is only broken for 0.25 percent of users of bumpversion --breaking. That should be acceptable. I will have a look.

@mauritsvanrees mauritsvanrees self-assigned this Mar 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants