PostRelease Not Incrementing Version Correctly

[bbarney213]

I am trying to get zestreleaser working with my project, but I am having issues with the postrelease command.

Running postrelease when the version number is set to '3.0.4' works as expected and updates it to '3.0.5.dev0'.

If I run the command again, this is what I get:

` (base) C:\Users\b.barney1\Documents\GitHub\PyLendingClub>postrelease -v DEBUG: Running command: 'c:\users\b.barney1\appdata\local\continuum\anaconda3\python.exe setup.py egg_info' DEBUG: Stderr of running command 'c:\users\b.barney1\appdata\local\continuum\anaconda3\python.exe setup.py egg_info': warning: no files found matching 'appveyor.yml' warning: no previously-included files matching 'pycache' found anywhere in distribution warning: no previously-included files matching '.so' found anywhere in distribution warning: no previously-included files matching '.dylib' found anywhere in distribution

DEBUG: Running command: 'c:\users\b.barney1\appdata\local\continuum\anaconda3\python.exe setup.py --name' DEBUG: Running command: 'git symbolic-ref --quiet HEAD' DEBUG: Running command: 'git status --short --untracked-files=no' DEBUG: Running command: 'c:\users\b.barney1\appdata\local\continuum\anaconda3\python.exe setup.py egg_info' DEBUG: Stderr of running command 'c:\users\b.barney1\appdata\local\continuum\anaconda3\python.exe setup.py egg_info': warning: no files found matching 'appveyor.yml' warning: no previously-included files matching 'pycache' found anywhere in distribution warning: no previously-included files matching '.so' found anywhere in distribution warning: no previously-included files matching '.dylib' found anywhere in distribution

DEBUG: Running command: 'c:\users\b.barney1\appdata\local\continuum\anaconda3\python.exe setup.py --version' DEBUG: Extracted version: 3.0.5.dev0 DEBUG: Version indicates development: 3.0.5.dev0. DEBUG: Removing debug indicators: '3.0.5.' Current version is 3.0.5 Enter new development version ('.dev0' will be appended) [3.0.6]: `

From what I understood, it should recognize that it is already on a dev release and should instead update to 3.0.5.dev1. Am I misunderstanding?

Thanks for your help!

[bbarney213]

From reading through the code, it looks like this is the culprit:

https://github.com/zestsoftware/zest.releaser/blob/fe1d8020faa86ae8e091ae1d7e59accd6b13f7b1/zest/releaser/postrelease.py#L64

utils.suggest_version would find the dev marker and increment appropriately: https://github.com/zestsoftware/zest.releaser/blob/fe1d8020faa86ae8e091ae1d7e59accd6b13f7b1/zest/releaser/utils.py#L242

https://github.com/zestsoftware/zest.releaser/blob/fe1d8020faa86ae8e091ae1d7e59accd6b13f7b1/zest/releaser/utils.py#L260

but the cleanup_version command strips out the dev marker before a suggestion can be made. https://github.com/zestsoftware/zest.releaser/blob/fe1d8020faa86ae8e091ae1d7e59accd6b13f7b1/zest/releaser/utils.py#L217

Is there a reason for cleanup_version to always be called before suggest_version? It seems like suggest_version assumes that the dev marker (and other markers) might be present, but this wouldn't ever be the case as long as cleanup_version works appropriately.

[mauritsvanrees]

So you are calling postrelease twice, right? There should be no reason for that. You should run prerelease, then release, then postrelease (or fullrelease for all three). Why are you calling it twice?

postrelease currently expects to get a clean version without dev marker, like it would get after running release. If it gets a dev marker anyway, it assumes something went wrong, and it cleans it. After user input it appends .dev0, never .dev1. So you get this question:

Enter new development version ('.dev0' will be appended) [3.0.6]:

You could manually answer 3.0.5.dev1, but the end result would then be 3.0.5.dev1.dev0, which is not what you want.

What it boils down to, is that zest.releaser does not really want you to create releases that contain development markers. Maybe the note at the end of the Developmental releases section of PEP 440 explains that better.

If you want to support this better, it could probably be done in a package that hooks into the entry points of zest.releaser and plays with the postrelease data dict items/

[bbarney213]

I was calling postrelease twice to test it to make sure the functionality was working as expected. The idea was that, as I am working on the project and committing it I would use post-release and a dev marker to indicate that it is in development. The initial postrelease would be .dev0, then .dev1, etc.

If zest.releaser doesn't want to support post-releases, why include it as a feature? It seems strange that there would be a command that doesn't work as expected to discourage use versus simply not including the functionality and making a note on the readme to indicate the reasoning. Perhaps updating the Readme to indicate this is warranted?

It also seems strange that it would assume that something went wrong if a dev marker is present, when there is also code in there to handle an existing dev marker and to then increment it. I may be misreading the code, but from what I could tell, simply not stripping the dev marker before getting the new marker would increment as expected.

[mauritsvanrees]

Ah, that is where the confusion is. postrelease does not make a post release. It does some actions that you would otherwise manually do after (post) a release. Likewise, prerelease does not make a pre release, but it does some actions that you would otherwise manually do before (pre) a release. See the explanation on readthedocs.