postrelease minor/patch version

[rnc]

We have started using this in https://github.com/cekit/cekit and its really useful!

We tend to use version formats of e.g. 3.10.0. What would be useful if during postrelease, it could prompt to update to 3.11.0. I see that postrelease uses the same suggest_version version code that bumpversion uses but it doesn't support --feature. If it supported that, then it could either bump to a patch release or to the next minor ?

[mauritsvanrees]

If we add it to postrelease, then it only makes sense to also add it to fullrelease, because this basically calls prerelease && release && postrelease. But what would fullrelease --feature do? Would it prompt to update to 3.11.0 in the prerelease phase? Or in postrelease? Or both? I don't know.

I don't see that typing postrelease --feature is any less work than typing postrelease and when prompted type 3.11.0. The only downside is that you can't automate such a reply. But if you want to automate it, you can do this (assuming git for version control):

postrelease --no-input && bumpversion --feature --no-input && git push

Also, If you always have .0 as micro version, then you might as well simply use 3.10 as version, and postrelease will bump that to 3.11. Maybe you can experiment with the options less-zeroes and version-levels. See the docs. I don't see that this is

[rnc]

@mauritsvanrees I have experimented with less-zeros and version-levels but as far as I could see none allow me to retain patch levels but use minor increments in a standard release process. If you could show me how that would work that would be great!

We don't use fullrelease but do use prerelease , release, and postrelease i.e. https://github.com/cekit/cekit/blob/develop/Makefile#L44

p.s. I think your last sentence got cut off.

[mauritsvanrees]

Ah, you can ignore my last half sentence, sorry.

With less-zeroes = no and version-levels = 2 you could let postrelease propose 3.11, but I don't see a way to come to 3.11.0 no.

[rnc]

Thanks for the replies.

I think the problem is at the moment a semantic versioned release can only suggest patch versions which isn't ideal.

Ideally there should be some configuration ability to suggest minor version for the next version (be that through postrelease or fullrelease). And given the same utility function is being used as bumpversion which does support semanticversion minor/patch releases it would seem to make sense to copy the existing feature argument flags so that it would work for those as well.

[rnc]

Mentioned before in #177 and #350

[rnc]

@mauritsvanrees I have tried using bumpversion --feature before postrelease but I get

 bumpversion --feature                                                                                                                                                                                    cekit-doByqAv5🏷 3.11.0 9:52
Checking version bump for feature 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: 3.11.0
Current version: 3.11.0
WARNING: No history file found
Enter version [3.12.0]: 
INFO: Set __version__ in cekit/version.py to '3.12.0'
INFO: Changed version from 3.11.0 to 3.12.0
INFO: The 'git diff':

diff --git a/cekit/version.py b/cekit/version.py
index 0d54f19..9ed9aaf 100644
--- a/cekit/version.py
+++ b/cekit/version.py
@@ -1,2 +1,2 @@
-__version__ = "3.11.0"
+__version__ = "3.12.0"
 schema_version = 2
diff --git a/setup.cfg b/setup.cfg
index 2cd1edc..b0b68c7 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -1,3 +1,3 @@
 [zest.releaser]
 python-file-with-version = cekit/version.py
-less-zeroes=True
+less-zeroes=no

OK to commit this (Y/n)? 
INFO: [ISSUE708 4a1dd9e] Bumped version for feature release.
 2 files changed, 2 insertions(+), 2 deletions(-)
postrelease                                                                                                                                                                                              cekit-doByqAv5🏷 3.11.0 9:53
Current version is 3.12.0
Enter new development version ('.dev0' will be appended) [3.13.0]: 
INFO: New version string is 3.13.0.dev0
WARNING: No history file found
INFO: Set __version__ in cekit/version.py to '3.13.0.dev0'
INFO: The 'git diff':

diff --git a/cekit/version.py b/cekit/version.py
index 9ed9aaf..f6ba879 100644
--- a/cekit/version.py
+++ b/cekit/version.py
@@ -1,2 +1,2 @@
-__version__ = "3.12.0"
+__version__ = "3.13.0.dev0"
 schema_version = 2

OK to commit this (Y/n)? 

In other words, I can't use bumpversion and postrelease although bumpversion does then allow it comply with the semantic version scheme.

Would you be willing to accept a PR to change postrelease to accept a --feature argument ?