Open andrewegel opened 3 years ago
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
.bumpversion.cfg
file for the 'base' version.base
first...end of range
files using the second config file, and use the --new-version
argument.I'm glad we came to similar conclusions separately:
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.
Let me lead by an example - this commit is a version bump from
6.1.0-0
to6.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:
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:[1] https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html