If we bump everything to 6.x including bugs, people can lazily evaluate when they work on them as to how far back the bugfix should apply. So either way (over-rotate and proactively flag too many for 5.0.x, just bulk them all to 6.x and add back on completion), we should theoretically end up with the same final outcome.
I think the straight bump to 6.x is probably better since having missing information is less misleading than having *bad* version targeting information. On Sat, May 17, 2025, at 10:30 AM, Mick Semb Wever wrote: > . > > On Sat, 17 May 2025 at 14:57, Josh McKenzie <jmcken...@apache.org> wrote: >> __ >> With the dropping of .MINOR in semver simplifying some things in our release >> we have some FixVersion updating to consider. >> >> For those that might not know - we use the ".X" FixVersion to indicate >> something is intended for a specific release line, then resolve the "X" to >> the number of the release it's merged into. For example, if the current >> major release is 5.0.4, a ticket intended for that line would have >> FixVersion "5.0.x", then on merge, would get the next unreleased version in >> that line "5.0.5". >> >> I searched on our wiki and don't see this documented actually; might be good >> to document this on our Release Versioning wiki article >> <https://cwiki.apache.org/confluence/display/CASSANDRA/Patching%2C+release+versioning%2C+and+LTS+releases>. > > > > Currently this is only documented on the jira version descriptions. To wiki, > yes please! > > > >> >> With the move away from .MINOR, we need to figure out what we want to do >> with the "5.x" FixVersion tickets. Here's a breakdown of count by type >> w/links to JQL queries: >> • All 5.x tickets: 761 >> <https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%205.x%20and%20resolution%20%3D%20unresolved> >> • New Feature: 91 >> <https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%205.x%20and%20resolution%20%3D%20unresolved%20and%20type%20%3D%20%22new%20feature%22> >> • Improvement: 326 >> <https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%205.x%20and%20type%20%3D%20improvement%20and%20resolution%20%3D%20unresolved> >> • Bug + Task: 304 >> <https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%205.x%20and%20resolution%20%3D%20unresolved%20and%20type%20in%20(bug%2C%20task)> >> (233 >> <https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%205.x%20and%20resolution%20%3D%20unresolved%20and%20type%20in%20(bug%2C%20task)%20AND%20fixversion%20!%3D%205.0.x> >> are 5.x only w/out 5.0.x; probably need to update these...) >> My initial thought on how we tackle this: >> 1. Replace "5.x" in FixVersions with "6.x" >> 2. Add "5.0.x" to the 233 bug/task targeting "5.x" (w/the understanding >> some of those will actually be 6.x intended only) >> Thoughts? > > > > If things are correct, according to (the previous) plan it should just be > about moving all "5.x" tickets to "6.x" (and deleting "5.x). And also > renaming "5.1" to "6.0". But I'm not sure about adding "5.0.x" without any > inspection to whether a) we want the fix in 5.0.x and b) it's feasible to > fix it in a patch version. > > So > 1) yes > 2) no > > I'm sure there's plenty of 5.x bugs that should be 5.0.x, but I don't see > this a big concern (it gets addressed when it's worked on), and there's > plenty of tickets (786!) that are reported and remain without any fixVersion > at all. I of course don't have any objection to any committer triaging them > as appropriate for 5.0.x (and any earlier fixVersion), and updating them so. >
