@sbrudenell Thanks for this contribution! Much appreciated! 👍

I like it. 👍 My only concern is that this change breaks compatibility with previous releases, right? Maybe this change should go into semver 3?

Futhermore, we should document this behavior somewhere in docs/usage.rst. Maybe in Comparing Versions or in a separate section.
It doesn't need much. I would describe a general example and then give the specific one with a build part. That should include a text that the build part isn't taken into account.

Does that make sense to you?

IMO it's a stretch to say this change breaks compatibility. Technically true, but any code relying on the current behavior is relying on the python data model being broken, which is pathological enough that I wouldn't bother supporting it. Up to you though.

Is there a separate branch for changes going into 3.x?

I'll update the docs.

IMO it's a stretch to say this change breaks compatibility. [...]

Yes, maybe my question was not entirely correct. It was more of a "thinking out loud" approach and to get your opinion. Probably I'm too concerned about that, maybe it's not a big issue. 😉 But it's something that I consider first before accepting any PR. So let me think about that.

Is there a separate branch for changes going into 3.x?

At the moment this is not the case, unfortunately. I hope we can leave semver2 behind soon and start working on semver 3. For you, nothing changes at the moment.

I'll update the docs.

That would be great! 👍

I'm currently thinking if this change could be safely integrated into the current semver2 code stream or better added to semver3 only.

@tlaferriere @python-semver/reviewers Thoughts?

This does feel like a bugfix that could be integrated in the 2.12.x line. All we have to do is implement it 😉. So much for freezing 2.10.x 😂.
I don't have much spare time atm but I see you're on a roll @tomschr so if you feel like getting that done, it's up to you to decide whether you want to release it as a bugfix or in in the next major change.

I've tried to read the semver spec to find a dedicated section regarding to compare two versions. The closed I could find was §10:

10. [...] Build metadata MUST be ignored when determining version precedence.
Thus two versions that differ only in the build metadata, have the same precedence.

Although the spec talks about version precedence, I think, this can be interpreted as our use case. That makes this a bugfix that should be integrated into semver2 and 3.

Thanks @sbrudenell and @tlaferriere for your contributions and help! Much appreciated! 👍