Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.96%. Comparing base (aa82b98) to head (0f729c4).

@@ Coverage Diff @@
## master #1705 +/- ##
==========================================
+ Coverage 97.95% 97.96% +0.01% 
==========================================
 Files 60 60 
 Lines 2646 2660 +14 
==========================================
+ Hits 2592 2606 +14 
 Misses 54 54 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

As I mentioned in #1704, please publish the new version scheme as a third-party plugin.

You may either reuse this branch or create another branch to update the third-party plugin list. Thanks!

What should it be?

@Lee-W wdyt

Please let me know if any action is needed on my end ツ

@woile based on our design, I think 1.2 is essentially 1.2.0. Do you think there would be exception that these 2 are different?

Will send another PR to add the plugin documentation after the next release.

Thanks and happy holidays!

@Lee-W I usually understand 1.2 as the full range of versions: 1.2.0, 1.2.1, 1.2.3... etc. This in something like npm.

In the case that we are not talking about semver, the semantics could change and what we know would no longer apply. It would depend on how the version scheme is designed. For example, python itself doesn't use semver nor pep440. A bump like 3.12 to 3.13 introduces breaking changes, and even though they have patches, what people use is the major.minor to reference a version

Agreed with @Lee-W it needs documentation to be merged.

To me it also need more testing as I agree with @woile, to me 1.2 is the latest 1.2.x.

I fear this can have unexpected effects on repository maintaining Docker-like or github actions like tagging (which is my case on some repository):

• latest version is tagged x.y.z
• an action will automatically move the rolling tags x.y and x to match

So in the case of a bump 1.2.3 from to 1.2.4, there will be a 1.2 and 1 tag on the same commit.

This case is relatively common and need to be tested (to avoid errors like duplicate tags).

Just following up, please let me know if you need any action from my side ツ

Agree with @woile and @noirbizarre , I guess that means we're not going to tackle this issue in this way. Probably make 1.2.x point to the latest version? I feel that would be a good v5 feature

Agree with @woile and @noirbizarre , I guess that means we're not going to tackle this issue in this way. Probably make 1.2.x point to the latest version? I feel that would be a good v5 feature

Got it, I started the work for it. Although, just want to mention that the change here (normalize_tag) will still be needed.
That line in normalize_tag is about formatting tags, not resolving "latest." When a user uses $major.$minor.$patch in tag_format, we still need a stable 3‐tuple even if the version is 1 or 1.2. Padding to 1.0.0 / 1.2.0 there is still correct and keeps tag rendering consistent.

For the change you mentioned, I will need to update the following function:

def find_tag_for(
 self, tags: Iterable[GitTag], version: Version | str
) -> GitTag | None:

What would happen without this fix? Specifically, we still need a stable 3‐tuple even if the version is 1 or 1.2. Padding to 1.0.0 / 1.2.0 there is still correct and keeps tag rendering consistent.

What would happen without this fix? Specifically, we still need a stable 3‐tuple even if the version is 1 or 1.2. Padding to 1.0.0 / 1.2.0 there is still correct and keeps tag rendering consistent.

The normalize_tag function is about reading the tags and extracting the version from them.
If we have the v12.3 tag and it tries to extract the version (Major, Minor, Patch) we get ValueError: not enough values to unpack (expected 3, got 2). (similarly for v5)

For the rest of the code to work, we need to default Patch (and Minor) to a value. In my change, I defaulted them to 0 since the value of that function is not being used to set any value. I could also default to None but since the expected type is not None it would have been too many changes across the codebase.

What would happen without this fix? Specifically, we still need a stable 3‐tuple even if the version is 1 or 1.2. Padding to 1.0.0 / 1.2.0 there is still correct and keeps tag rendering consistent.

The normalize_tag function is about reading the tags and extracting the version from them. If we have the v12.3 tag and it tries to extract the version (Major, Minor, Patch) we get ValueError: not enough values to unpack (expected 3, got 2). (similarly for v5)

For the rest of the code to work, we need to default Patch (and Minor) to a value. In my change, I defaulted them to 0 since the value of that function is not being used to set any value. I could also default to None but since the expected type is not None it would have been too many changes across the codebase.

I'm good with this change. but maybe let's add a warning here? like this is missed we fallback to 0 but in the future version (e.g., v5), we're going to change it. WDYT?

What would happen without this fix? Specifically, we still need a stable 3‐tuple even if the version is 1 or 1.2. Padding to 1.0.0 / 1.2.0 there is still correct and keeps tag rendering consistent.

The normalize_tag function is about reading the tags and extracting the version from them. If we have the v12.3 tag and it tries to extract the version (Major, Minor, Patch) we get ValueError: not enough values to unpack (expected 3, got 2). (similarly for v5)
For the rest of the code to work, we need to default Patch (and Minor) to a value. In my change, I defaulted them to 0 since the value of that function is not being used to set any value. I could also default to None but since the expected type is not None it would have been too many changes across the codebase.

I'm good with this change. but maybe let's add a warning here? like this is missed we fallback to 0 but in the future version (e.g., v5), we're going to change it. WDYT?

Sure thing, Shall I still keep the other change for resolving the latest version with the given prefix in find_tag_for function as well?

What would happen without this fix? Specifically, we still need a stable 3‐tuple even if the version is 1 or 1.2. Padding to 1.0.0 / 1.2.0 there is still correct and keeps tag rendering consistent.

The normalize_tag function is about reading the tags and extracting the version from them. If we have the v12.3 tag and it tries to extract the version (Major, Minor, Patch) we get ValueError: not enough values to unpack (expected 3, got 2). (similarly for v5)
For the rest of the code to work, we need to default Patch (and Minor) to a value. In my change, I defaulted them to 0 since the value of that function is not being used to set any value. I could also default to None but since the expected type is not None it would have been too many changes across the codebase.

I'm good with this change. but maybe let's add a warning here? like this is missed we fallback to 0 but in the future version (e.g., v5), we're going to change it. WDYT?

Sure thing, Shall I still keep the other change for resolving the latest version with the given prefix in find_tag_for function as well?

I don't get it 🤔 If we already have another function that can check the latest version (e.g., 1.2 -> 1.2.5 ), then we should use that here. If not, I would need you help to elaborate a bit. Thanks!

@Lee-W there are two changes in this PR:

• Update the normalize_tag function to handle tag versions with less than 3 components by masking with 0.0.0.

This is a fix to ValueError: not enough values to unpack (expected 3, got 2) when the git tags and version in pyproject.toml file has less than 3 components.

• Update the find_tag_for function to return the latest version matching with the given version prefix.

This is a new feature as we discussed in here. If we're referencing an uncompleted version (e.g. 1.2), it will retrieve the latest patch for that version. (e.g. 1.2.3)