bump_prerelease and bump_build return smaller version
See original GitHub issueThe current behavior of bump_prerelease
and bump_build
seems wrong, or at least unexpected:
In [64]: v1 = semver.parse_version_info('0.1.4')
In [65]: v1 < v1.bump_major() # good
Out[65]: True
In [66]: v1 < v1.bump_minor() # good
Out[66]: True
In [67]: v1 < v1.bump_patch() # good
Out[67]: True
In [68]: v1 < v1.bump_prerelease() # not good
Out[68]: False
In [69]: v1 < v1.bump_build() # not good
Out[69]: False
Is this deliberate? I would expect them to return what v1.bump_patch().bump_prerelease()
and v1.bump_patch().bump_build()
return now.
Issue Analytics
- State:
- Created 4 years ago
- Comments:13 (13 by maintainers)
Top Results From Across the Web
pysemver 3.0.0-dev.3 - Read the Docs
Bump a version. ... The part to bump. Valid strings are major , minor , patch , prerelease , or build . The...
Read more >fsaintjacques/semver-tool - GitHub
the BUILD part. \"bump release\" removes any PRERELEASE or BUILD parts. The bumped version is written to stdout.
Read more >python-semver Documentation - Read the Docs
bump_major leaves the original object untouched, but returns a new semver.Version instance with the raised major.
Read more >libcamera official repository
+ the BUILD part. \"bump release\" removes any PRERELEASE or BUILD parts. + The bumped version is written to stdout. +. + get...
Read more >bump-prerelease-version - npm
Bump your prerelease version. Latest version: 1.0.1, last published: 4 years ago. Start using bump-prerelease-version in your project by ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@tomschr thanks for taking the time to come up with a draft, I’ll take a look at it! The signature looks good, I agree that
build
is less important and clear; we can always extend it later if necessary.@tomschr The only other library I checked is python-semanticversion which doesn’t currently provide a method to bump prerelease (or build); I opened an issue for it.
Among the options you listed I’d be in favor of 4, though not specifically for the build part but all of them. A possible signature could be:
where
part
can be one of{"major", "minor", "patch", "prerelease", "build }
.By the way, the
0.1.4
→0.1.5-rc.1
transition isn’t the only problematic one:I would expect that the next patch version of
1.2.4-rc3
is1.2.4
, not1.2.5
.So currently there are two special cases, without even considering the
build
part.