Allow custom suffix / tag

[cswan-log]

Currently the TAG is fairly restricted. It would be great if this can be used more broadly.

For example we are releasing frequent "dev" versions which are build from the "develop" branch. Those are suffixed with -dev-SHA_OF_COMMIT to identify them as dev builds from a specific commit. This is needed since we currently using semver and the dev builds do not change the main version string which results in build like 2.1.0-dev-ahka131. Also the production builds are suffixed with the commit hash which allows us to link them directly with a commit.

Would it be possible to allow more different tags or a custom suffix?

[mbarkhau]

Isn't the ask here for a new part SHA_OF_COMMIT rather than anything to do with the TAG part?

[mbarkhau]

Hmm, I guess the issue with that might be the ordering of versions. 2.1.0-dev-ahka131 > 2.1.0-dev-131ahka though the latter might in fact be more recent.

[cswan-log]

Yeah, the ordering would be a bit wonky with this... So maybe a completetly custom suffix would be better suited for this situation? Thus when you are using it, you are aware that the ordering might be broken since the data is completetly up to you.

Related to the tag, the question was if it could be more broadly in terms of possible values or if this is restricted by the PEP schema? Any value like pre, dev etc. are useful but are forbidden with the current implementation.

[mbarkhau]

For the TAG part I think it would be ok to have other values. Currently the restriction is applied via this:

VALID_RELEASE_TAG_VALUES = ("alpha", "beta", "rc", "post", "final")

This could instead be taken from a config setting (accepting that pep440 normalization might be an issue).

[Merinorus]

Hi, I would also be interested in adding custom tags. In my case, I would like to tag an intermediate version with a particular feature, even if it's a pre-release, so I can have a reference for this feature later on. Eg:

• 2022.06
• 2022.06.1
• 2022.06.2-mycustomfeature
• 2022.06.3 Adding custom tags in the config file would be possible but still, it restricts the tagging possibilities.

I would prefer being able to simply write --tag=mycustomfeature. The difficulty, I guess, would be how the regex would apply if the tag isn't at the end of the string.

[mbarkhau]

The difficulty, I guess, would be how the regex would apply if the tag isn't at the end of the string.

I'm not sure that's a big issue. The syntax for optional parts translates to optional groups in a regex.

bumpver_pattern = "MAJOR.MINOR[.PATCH]"
regex_pattern = re.compile(r"""
    (?P<major>[0-9]+)
    \.
    (?P<minor>[0-9]+)
    (?:\.
        (?P<patch>[0-9]+)
    )?
""", flags=re.VERBOSE)

As I said with my comment from June 1st, ordering may be an issue. Currently the order for tags is well defined. If you can pick any string, which version is earlier than the other?

[Merinorus]

Oh, I see. In my case, I always increment the patch (or the last digit part in the general case). Eg:

• 2022.06
• 2022.06.1
• 2022.06.2-mycustomfeature
• 2022.06.3-unrelatedfeature
• 2022.06.4-yetanotherfeature
• 2022.06.5-rc
• 2022.06.6-beta
• 2022.06.7
• 2022.07

I order the release with digits only.

I guess you can or cannot use lexicographical ordering depending on the versioning logic, and if you want to ensure order in your release, you should use a pattern that should maintain lexicographical ordering.

[mbarkhau]

Sounds like a foot-gun, but if people know what they're doing, I'm inclined to not stand in their way. If you want to work on a PR for this, I'll be happy to help you along.

For people who don't want to use this feature, I'd prefer to not just accept any value for --tag <NAME>. Instead the config can enable this behavior with a setting allow_custom_tags and only then bumpver would just accept whatever is given as a parameter. I think valid tags would have to match [a-z][a-z0-9_]*

[Merinorus]

Seems good to me! I'll think about a PR in this way.

[Merinorus]

Hello, Sorry but I don't think I will be able to work on it soon. I'm trying to find out how this works but this takes more time than I expected... If someone wants to take this one, feel free to spy on my branch: https://github.com/merinorus/bumpver/tree/allow-custom-tag

[sharonyogev]

For the TAG part I think it would be ok to have other values. Currently the restriction is applied via this:

VALID_RELEASE_TAG_VALUES = ("alpha", "beta", "rc", "post", "final")

This could instead by taken from a config setting (accepting that pep440 normalization might be an issue).

I've opened this PR here: https://github.com/mbarkhau/bumpver/pull/199

[mbarkhau]

Thanks @sharonyogev I'll have time to look at this later this month.