Specifically, if anyone's interested, I think we should probably maintain three
tags for work landing in 4.0, e.g. 4.0-alpha1, 4.0-alpha, 4.0
This helps track all of the relevant information, the first limited release,
the first general release, and the point in the release process it was
delivered.
On 15/01/2020, 13:34, "Benedict Elliott Smith" <bened...@apache.org> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
