IMHO, stability and manageability (want to have the old (2.1) full repair 
behavior back 😊, yes I followed the repair scheduling thread here) should be 
the top priority before adding any new CQL enhancements or whatever. 
Manageability improvements even treated for backports into 3.11.x, as it seems 
4.0 is a long way ahead for production usage.

Just my 2 EUR cents. 😊


-----Original Message-----
From: Nate McCall []
Sent: Freitag, 06. April 2018 06:01
To: dev <>
Subject: Re: Roadmap for 4.0

>> So long as non-user-visible improvements, including big ones, can
>> still go in 4.0 at that stage, I’m all for it.
> My understanding is that after June 1st the 4.0 branch would be
> created and would be bugfix only. It's not really a feature freeze if
> you allow improvements after that, which is why they'd instead go to trunk.
> I'm also on the "too soon" train so pushing it back to August or so is
> desirable to me.

For those wanting to delay, are we just dancing around inclusion of some pet 
features? This is fine, I just think we need to communicate what we are after 
if so.

We can do two things:
1. Lay our cards on the table about what we want included in 4.0 and work to 
get those in 2. Agree to keep June 1 follow up a lot quicker with a 4.1

I do want to remind everyone though that each new feature is at odds with our 
stability goals for 4.0.

To unsubscribe, e-mail:
For additional commands, e-mail:

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

Reply via email to