Just realized I'd misunderstood Mick's original email, apologies. I'd originally interpreted it as a question of prioritization, but the intent was to ensure that the Fix Version field reflects the release a given change is /included in/, not /originally targeted for/. Apologies for my misunderstanding.
Agreed yes; it'd make sense to update recently-committed items that have a future fix version to indicate they were resolved during alpha. I haven't seen fix version refer to specific alpha releases (given that there's just one at the moment), but agree that it would be useful to differentiate between which alpha/beta/RC build a given change lands in. Thanks Mick! – Scott ________________________________________ From: Mick Semb Wever <m...@apache.org> Sent: Tuesday, January 14, 2020 12:44 PM To: dev@cassandra.apache.org Subject: Re: Cassandra 4.0 Dev Work Status > I think the intent of the milestones is meant to indicate that > contributors view completion of those items as exit criteria for alpha > / beta / RC; not necessarily that all items will be completed in strict > order. Yeah, though there's a nuance here between the ticket milestone when it is open and the version it becomes available in. That is milestones are indicated by the fixVersions field while a ticket is open, and with the ".x" suffixed versions. And when the ticket gets resolved/closed the fixVersion is then updated to the exact version it becomes available in. But given that we don't actually have those exact alpha1, alpha2, etc versions, maybe i missed a piece of info along the way, and this isn't true for the alpha/beta/RCs ? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
