QUERY: Support for version ranges?

[andrewegel]

Let me lead by an example - this commit is a version bump from 6.1.0-0 to 6.2.0-0:

https://github.com/confluentinc/common/commit/affc70782822ba0ce38c8b56f5478bf119e0bcee

That commit, while from a person, was performed with some proprietary tooling - I'm currently evaluating if this project could replace that tooling, in either a part, or wholesale.

This is a maven project that has started using nano-versioning ranges in its pom files [1] in the form:

[<current-version>, <next-part-version>)

Where <next-part-version> and the trailing ) indicate that maven can use any nanoversion up-to <next-part-version> - I'm looking into the feasibility of bump2version to handle this sort of bump for us, currently this isn't "modeled" in a sense, as <next-part-version> would be the "next next" version (but not really, it would be up-to-the-next-patch version), from looking at the code base I don't see anything like this, and I'd like to gauge how the maintainers:

• Think if this is as good idea
• Any suggestions on how it could be implemented
• Maybe this is implemented someway now with some "tricky" config file directives.

[1] https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

[florisla]

So

[6.2.0-0-ccs, 6.2.1-0-ccs)

Means compatibility starts with version 6.2.0-0 and ends when 6.2.0 becomes 6.2.1 or higher.

I don't think you can express such a thing in bump2version directly. You're basically tracking two version numbers, albeit that the second one can be derived from the first one.

Bump2version is really oriented towards a single version number.

I think a working flow with bump2version would go like

• Have a .bumpversion.cfg file for the 'base' version.
• Have a separate config file for the 'end of range' version.
• When bumping, bump base first...
• Log the 'base' version in a file.
• Use a bump2version command to turn the 'base' version into a new 'end of range' version.
• Then bump end of range files using the second config file, and use the --new-version argument.

[andrewegel]

I'm glad we came to similar conclusions separately:

• Bump2version is really oriented towards a single version number.
• Have a .bumpversion.cfg file for the 'base' version.

Therefore maybe a proposed idea would be to have bump2version perform multiple bumps based on a lexicographical "glob". What I mean by this is besides recognizing just .bumpversion.cfg, it would see .*.bumpversion.cfg-globed files, and run bump2version <part> in a lexagraphical sort. Ie:

.00-bump-upper.bumpversion.cfg -> Bump Upper Range. .99-bump-base.bumpversion.cfg -> Bump everything else.