I think there's always been a distinction in the way we treat alphas/betas
versus patch releases, because they have a staged delivery (landing for dev and
users in different releases). I don't know we've ever been totally consistent
about it across major versions though.
I think we can view 4.0-alpha as equivalent to 4.x, except that it has value
being maintained after commit, to historically track where things land in the
release process. It was discussed somewhere, not ages ago and I can't remember
where, that there was value in this. There's probably also value in
introducing 4.0-alpha1 etc on top.
We should probably decide and document it, as you say, so that we can at least
be consistent next major.
On 15/01/2020, 13:18, "Joshua McKenzie" <jmcken...@apache.org> wrote:
Historically I believe we used the ".x" nomenclature to indicate general
release we wanted things in (4.x, 3.11.x, 3.6.x, etc), and then upon merge
update the FixVersion to reflect which release it actually went in. Is that
still a thing, and whether a thing or not, is the current appropriate usage
of FixVersion on the project documented somewhere?
On Wed, Jan 15, 2020 at 2:24 AM Scott Andreas <sc...@paradoxica.net> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
