> > Alternatively, we could revert to using 4.0.X or 4.X as we once did to > indicate something is targeting a release vs. blocking on inclusion for it. > That seems to be a more "project JIRA hackish idiom", and one that's > historically been confusing for people. At least with a label it would be > clear with a name like "4.0-blocker", and we could then easily filter the > JIRA board on it. >
Now that I better understand Benedict's previous response (see the 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view for now. I certainly missed the difference on how tickets ended up resolved as `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could still go into `4.0-alpha` if they satisfied the feature freeze and met someone's itch, while the unresolved `4.0-alpha` tickets were those the community declared as blockers. Putting aside the discussion on what is a blocker, when it is discovered to be a blocker (and vice versa). My confusion stemmed from the fact there was no specific alpha|beta versions for tickets to get resolved into, eg 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x` nomenclature got changed, but having accurate fix versions was also removed. If we added the specific alpha|beta versions then I wouldn't consider the approach to be a "hackish idiom" anymore. The 4.0-alpha, 4.0-beta and 4.0, versions become purely target versions like the `.x`, and no resolved ticket is ever assigned them. The simpler we can make and document this the better. please. regards, Mick ¹) https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
