Support for segment aliases?
See original GitHub issueFrom PEP 440:
Pre-releases allow the additional spellings of alpha, beta, c, pre, and preview for a, b, rc, rc, and rc respectively. This allows versions such as 1.1alpha1, 1.1beta2, or 1.1c3 which normalize to 1.1a1, 1.1b2, and 1.1rc3. In every case the additional spelling should be considered equivalent to their normal forms.
In other words, here:
- beta/b are aliases
- alpha/a are aliases
- rc/r are aliases
in this scheme.
I realize bump2version is not designed to cater to PEP440’s schema, per se, but this concept of aliasing certain parts (rather than requiring that values
is sequential) extends to other slightly different schemes also.
I have a half-baked feature branch that partially implements the ability to specify aliases in bumpversion values
config. For instance, it allows
values =
dev
alpha,a
beta,b
rc,c
What I have actually found challenging, because there is a good deal of ambiguity involved, is how optional_value
and first_value
would need to be/allowed to be specified.
Questions for @c4urself and @ekohl
- Thoughts on usefulness of adding this feature?
- Does there seem to be any more intuitive way to allow the user to specify aliases versus the example shown above?
- Thoughts on how strict you’d want to be about what correspondingly would be accepted as
optional_value
/first_value
?
It would come down to something like setting section_config["values"]
in cli.py
to have some list/tuple elements rather than just str, with some corresponding changes in version_part.py
and functions.py
.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5
Top GitHub Comments
You could consider leaving
values
as-is showing the canonical (or preferred) names, and introducing another keywordaliases
.Do you support serializing with aliases as well?
If you only care about parsing the aliases, then bump2version will never put an alias in a file? You would need to manually edit the version to introduce them, and they would disappear on the next bump.
Edit: just found #174, which might be relevant for context.