Charting / Tree view changes ETA

A while back I asked about upcoming charting changes and learned that charting is in flux currently in Perspective as you evaluate various technologies.

Can I get an update on where things stand with this? I have a customer asking me about this and they’d like a rough ETA. We understand that nothing is set in stone.

I’m also interested in any coming changes for the tree view. Unless I’m doing something wrong it appears that the tree view only allows single selection. I am trying to set up a tree view as my tag viewer and using that to dynamically select what displays on an XY Chart. That can’t be done if I can only select one item on the tree at a time.

We understand that neither of these things are in the scope of what’s expected with the 8.0 launch. We’re just trying to gauge if/when we can expect these things in the future so we set expectations properly.


My customer is meeting with a stakeholder today at 2 EST. They were hoping to have an official update on ETA for charting changes. They asked me to ask again here.

I’m sure you guys are super busy and I don’t want to be a pest. If you can give a rough idea of when we can expect charting updates it would be helpful to me.


Probably not 8.0.1, at this point. We’re going to be working on a much more regular release cycle for 8.0, so minor updates should be out monthly. Taken with a huge grain of salt, that means absolutely no earlier than June, and very possibly later than that. It’s high on our list, but once 8.0.0 is out “in the wild” so to speak, there’s a decent chance we end up with a long list of bugs to fix that may take priority.

Oh, perfect - there’s a blog post with more details on the faster release cycle:


Thanks for the update. Makes sense.

Given how quickly 8.0’s been evolving, I hope that there will still be a nightly/semi-nightly version for people who can put up with a bit more instability. The regular cadence of bug fixes and important feature landings was a big part of why we adopted 8.0 as the future, and monthly is a long time for ongoing development to sit on bugs. (Even if that means more in-house testing.)

The plan is to continue nightly releases with the expectation that anyone who elects to take such a build would understand that the build is strictly to be used to verify bug fixes that the user is encountering already, and the build should never be used in a production setting.

This would allow users to verify a bug fix meets their requirements and begin working with the new build before adopting the stable release a few weeks later.

Unfortunately, even though the cadence will be much more regular and releases will drop more often, it won’t change the fact that we can’t fix everything within one or two releases, and many tickets will still fall in the “yes, it’s broken, but everything else is more important” bucket.


If you haven’t read the blog entry Paul linked above, go do so right now. No speculation required.

1 Like