I would also suggest adjusting the commit message to give a hint of where this update occurred, for example:

Clarified Trac "version" attribute semantic in contributing guide.

Do we have a non-internal information about the issue fields? I always thought this field indicates which version the issue targets, and had no idea it was about where it can be reproduced.

In short, no, unless there is information in Trac's wiki.

Happy to clarify further, what does "targets" convey in this context?

Happy to clarify further

✨

what does "targets" convey in this context?

I'm not sure what the correct term is or how this is defined in different software, but I was acknowledging it as "This will be fixed in version x" (similar to Jira's take on the field). When I see an older version, my thinking was "oh this was originally targeted to 3.2, but now we have 5.2 and it should be updated". My expectation for the default value was the latest main (I guess we call it "dev" in this context)

Ah, makes sense. I think a notion of "targeting" makes more sense in other development workflows than ours, with stricter roadmaps. With our volunteer-driven, time-based release process, we do very little "targeting"; instead things land when they're ready.

When I see an older version, my thinking was "oh this was originally targeted to 3.2, but now we have 5.2 and it should be updated"

Instead, I think features and optimizations should just be set to dev, but bugs can be marked with a version to help us reason about whether or not they're recent regressions that qualify for a backport. My hope is that makes things clear, helpful for filtering, and reduces frequency of updates in Trac.

With our volunteer-driven, time-based release process, we do very little "targeting"; instead things land when they're ready.

I think features and optimizations should just be set to dev, but bugs can be marked with a version to help us reason about whether or not they're recent regressions that qualify for a backport.

I'm not sure I agree or disagree with these points, but I'm even more sure that what we use that field for is a bit different from the standard, and it needs a better explanation for a (non-triager) user who is checking Trac .