Add --feature and --breaking flags to postrelease and fullrelease

[yahel2410]

I'm using zest.release in an automated CI process, with the --no-input flag. When using this version format x.y.z, postrelease and fullrelease always bump the patch (z) part. Is it possible to bump the minor part (y) instead?

[reinout]

You could use bumpversion --feature beforehand? That doesn't do any releasing, it just modifies the version number. Then a later fullrelease will default to that version. This is what happens when I call it on zest.releaser itself:

$ bumpversion --feature
Checking version bump for feature release.
Last tag: 6.20.1
Current version: 6.20.2.dev0
Enter version [6.21.0.dev0]: 
INFO: Set setup.py's version to '6.21.0.dev0'
INFO: Changed version from 6.20.2.dev0 to 6.21.0.dev0
INFO: History file CHANGES.rst updated.
INFO: The 'git diff':

diff --git a/CHANGES.rst b/CHANGES.rst
index 9e296cb..14edc85 100644
--- a/CHANGES.rst
+++ b/CHANGES.rst
@@ -1,7 +1,7 @@
 Changelog for zest.releaser
 ===========================

-6.20.2 (unreleased)
+6.21.0 (unreleased)
 -------------------

 - Nothing changed yet.
diff --git a/setup.py b/setup.py
index f057f6d..27fe143 100644
--- a/setup.py
+++ b/setup.py
@@ -5,7 +5,7 @@ from setuptools import find_packages
 from setuptools import setup

-version = '6.20.2.dev0'
+version = '6.21.0.dev0'

 def read(filename):

You could also look at your versioning scheme. If you always want to go from 1.2.0 to 1.3.0 instead of to 1.2.1: why not name your release 1.2? Then zest.releaser will default to 1.3.

[yahel2410]

Thanks for the quick reply!

I tried your first suggestion - using bumpversion before release does solve half of the problem. But when I run fullrelease afterwards to bump again with the dev marker, it bumps the patch part. Let's say I just released 1.2.0, I would like to have 1.3.0-dev in setup.py after that, in order for the developers to know what future version they're working on.

Regarding you 2nd suggestion - I do need the x.y.z scheme, because I do intend to bump the patch part on hotfixes (using conditionals on the in the CI job)

[reinout]

Python's version handling treats 1.2 and 1.2.0 the same, if I remember correctly. So releasing 1.2 doesn't prevent you from doing a hotfix 1.2.1 (I think). I know I have done *.1 releases because I messed up something :-)

There's no way, in any case, that zest.releaser can know whether you want to go from 1.2.0 to 1.2.1 or 1.3.0. So if we want to support that, it'll mean an extra setting.

"disregard_dot_zero" or something like that? Then 1.2.3.0 would turn into 1.2.4.0. What about 1.0.0? I'd say, 1.1.0, not 2.0.0. So the setting should only work for the last level.

I suspect there are a few corner cases I haven't thought about yet.

[yahel2410]

Oh, when I rethink about it you're right about the later bump. I guess I'll have to live with x.y.1 in setup.py until the next release cycle.

Anyway, thanks! this helped me a lot.