The new release lifecycle guarantees changes these dynamics. Given our
commitment to API stability between beta 1 and GA, this has introduced a
time where changes being deferred to the next major due to API modification
will be unable to be merged unless we branch upon beta.
This warrants another
>
> Also, what is the plan for cutting beta branch? I am still learning the
> Apache/C* way so excuse me if I missed something. Looking at the Lifecycle
> document, I see a point only about GA major version branch.
> My understanding is that we are already in freeze for big changes. When
> would b
gt;>>>>> broaden
> > >>>>>>>> scope I think.
> > >>>>>>>>
> > >>>>>>>> One thing we're not considering is the separation of API changes
> > >>>> from
> > >>>>>
se
> >>>>>>>> 2. Milestone: API freeze (all API changes pushed to next major)
> >>>>>>>> 3. beta phase
> >>>>>>>> 4. Verification phase (all major disruptive pushed to next
> >>> major)
> >>>>>>>&g
eaning:
> >>>>>>>> 1. alpha phase
> >>>>>>>> 2. Milestone: API freeze (all API changes pushed to next major)
> >>>>>>>> 3. beta phase
> >>>>>>>> 4. Verification phase (all major disruptive p
gt;>>>>>>> an RC before broad verification seems wrong, and cutting an RC
>>>> after
>>>>>> the
>>>>>>> 4
>>>>>>>> points above may as well be GA because it's all known scope.
>>
;> > > > > >> will shrink dramatically in the not too distant future -
>> ideally
>> > to
>> > > a
>> > > > > >> period of less than a month. In this world, the cost of missing
>> > one
>> > > > > train
>> >
> to
> > > > > >> "test engineering" is automating as many aspects of release
> > > > > qualification
> > > > > >> as possible, with an asymptotic ideal as a function of compute
> > > > capacity
> > > >
> > >> as possible, with an asymptotic ideal as a function of compute
> > > capacity
> > > > and
> > > > >> time. While such automation will never be complete (it's likely
> that
> > > > >> development of new features
; capacity
> > > and
> > > >> time. While such automation will never be complete (it's likely that
> > > >> development of new features will/must include qualification infra
> > > changes
> > > >> to exercise them), if we're able to
effort, I'd be
> > >> thrilled.
> > >>
> > >> This is mostly a way of saying:
> > >> – I like the cadence/sequencing Benedict proposes below.
> > >> – I think improvements in test engineering can reduce/eliminate
> > >> invalid
t;> as we are to patchlevel builds with little incremental effort, I'd be
> >> thrilled.
> >>
> >> This is mostly a way of saying:
> >> – I like the cadence/sequencing Benedict proposes below.
> >> – I think improvements in test engineering can reduc
> merge on a given branch
>> – And if not, the cost of missing the train is lower because we'll be able
>> to deliver major releases more often.
>>
>> Scott
>>
>>
>> From: Jeremiah D Jordan
>> Sent: Wednesd
ses more often.
>
> Scott
>
> ____
> From: Jeremiah D Jordan
> Sent: Wednesday, May 27, 2020 11:54 AM
> To: Cassandra DEV
> Subject: Re: [DISCUSS] CASSANDRA-13994
>
> +1 strongly agree. If we aren’t going to let something go into 4
x27;ll be able to
deliver major releases more often.
Scott
From: Jeremiah D Jordan
Sent: Wednesday, May 27, 2020 11:54 AM
To: Cassandra DEV
Subject: Re: [DISCUSS] CASSANDRA-13994
+1 strongly agree. If we aren’t going to let something go into 4.0.0 because
it wo
+1 strongly agree. If we aren’t going to let something go into 4.0.0 because
it would "invalidate testing” then we can not let such a thing go into 4.0.1
unless we plan to re-do said testing for the patch release.
> On May 27, 2020, at 1:31 PM, Benedict Elliott Smith
> wrote:
>
> I'm being t
In this hypothetical, certainly not post-ga, and I'd argue we shouldn't
allow it post-beta1 and we need a clear demarcation of "this type of work
is ok to merge before X, it's not ok after X. Validation testing *will not
occur* before X, and will start after X".
It's a bit rigid, but it's the only
I'm being told this still isn't clear, so let me try in a bullet-point timeline:
* 4.0 Beta
* 4.0 Verification Work
* [Merge Window]
* 4.0 GA
* 4.0 Minor Releases
* ...
* 5.0 Dev
* ...
* 5.0 Verification Work
* GA 5.0
I think that anything that is prohibited from "[Merge Window]" because it
in
I'm not sure if I communicated my point very well. I mean to say that if the
reason we are prohibiting a patch to land post-beta is because it invalidates
work we only perform pre-ga, then it probably should not be permitted to land
post-ga either, since it must also invalidate the same work?
>
> because it invalidates our pre-release verification, then it should not
> land
until we next perform pre-release verification
At least for me there's a little softness around our collective alignment
on when pre-release verification takes place. If it's between alpha-1 and
ga we don't want ch
Thank you all for your input.
I think an important topic is again to revise the lifecycle and ensure we
really have the vision on what is left until beta. I will start a separate
thread on the flaky tests situation soon.
For this particular ticket I see a couple of things:
- There are a lot of del
I think our "pre-beta" criteria should also be our "not in a major" criteria.
If work is prohibited because it invalidates our pre-release verification, then
it should not land until we next perform pre-release verification, which only
currently happens once per major.
This could mean either l
I think an interesting question that informs when to stop accepting
specific changes in a release is when we expect any extensive pre-release
testing to take place.
If we go by our release lifecycle, gutting deprecated code seems compatible
w/Alpha but I wouldn't endorse merging it into Beta:
http
> 1) Would you block the release over this ticket?
I would definitely not block the release on this ticket.
> 2) Would you prioritize this ticket over testing?
Same here, I would prioritise testing.
> 3) Does fixing this ticket make 4.0 a more stable release?
I wanted to give some context: I w
Dear all,
Following the ticket review sent on 12th May I wanted to bring up
https://issues.apache.org/jira/browse/CASSANDRA-13994: Remove COMPACT
STORAGE internals before 4.0 release.
It is already under review by Dinesh Joshi and Alex Petrov. Not a
blocker but already under review.
Below are m
25 matches
Mail list logo
