Daklu Posted September 30, 2009 Report Share Posted September 30, 2009 I know several users here participate in Labview betas when they come up. I typically do not, primarily because I'm worried the software I produce will be less stable or will have to be rewritten after I've used some beta feature that ends up getting cut. I'm can deal with design-time issues such as random crashes or incorrectly rendered graphics, but the software I deploy cannot be beta quality. (Unless, of course, it's a beta version of my software.) For those that do participate in the beta, how do you minimize risk to your projects while still adequately testing Labview's new beta functions? Quote Link to comment
Daryl Posted September 30, 2009 Report Share Posted September 30, 2009 I know several users here participate in Labview betas when they come up. I typically do not, primarily because I'm worried the software I produce will be less stable or will have to be rewritten after I've used some beta feature that ends up getting cut. I'm can deal with design-time issues such as random crashes or incorrectly rendered graphics, but the software I deploy cannot be beta quality. (Unless, of course, it's a beta version of my software.) For those that do participate in the beta, how do you minimize risk to your projects while still adequately testing Labview's new beta functions? I have participated a few times but it got to be a pain so I quit doing it. Best way to minimize risk is to quit doing it Quote Link to comment
ShaunR Posted September 30, 2009 Report Share Posted September 30, 2009 oooh. You should never ship products developed with beta environments. Beta stuff is for larking around with, seeing what new features will be available and seeing if they have fixed the other bugs from previous version....Oh, and help them debug too I personally wont develop customer software on anything unless it has been out in the field at least 6-12 months. Then there should be a few patches around to get rid of the show-stoppers. And don't forget, there is no such thing as support for Beta software. If you find a show-stopper, it won't get fixed until it is released, and that could be a couple of months. Quote Link to comment
Daklu Posted September 30, 2009 Author Report Share Posted September 30, 2009 See... both of those comments reflect the prevailing opinion; one which I have long subscribed to and has merit. Yet people do participate in the beta testing, and unless they spend an inordinate amount of time playing with Labview on the weekends (*cough cough*) they must be doing it at work, where there is the additional requirement of being productive. I'm just wondering what others do to minimize, not eliminate, the risk. I develop engineering test tools for internal customers so my apps don't need to have the same level of polish as you'd expect from hiring a 3rd party firm and some risk may be acceptable. Does NI use their betas as a user research platform or is it strictly for code verification? Is the beta feature set typically fairly well locked down? How successful have you been backsaving projects developed with the beta to previous released versions? If you compile a beta project into an executable does it have the same instabilities you find in the IDE? If you've developed VIs using the beta, do you find you have to make lots of modifications when the final version is released or is it usually a few minor tweaks here and there? Quote Link to comment
Rolf Kalbermatter Posted September 30, 2009 Report Share Posted September 30, 2009 oooh. You should never ship products developed with beta environments. Beta stuff is for larking around with, seeing what new features will be available and seeing if they have fixed the other bugs from previous version....Oh, and help them debug too I personally wont develop customer software on anything unless it has been out in the field at least 6-12 months. Then there should be a few patches around to get rid of the show-stoppers. And don't forget, there is no such thing as support for Beta software. If you find a show-stopper, it won't get fixed until it is released, and that could be a couple of months. There is another problem with the latest LabVIEW versions including the Betas. Installing them will change the actual environment your earlier already installed LabVIEW versions will operate in in many ways. Various supporting components get updated, Toolkits get updated even in earlier versions behind the back (for instance the Vision module changes all VI libraries as far back as LabVIEW 7.1 and suddenly an application built in this earlier LabVIEW version AFTER the installation of LabVIEW 8.6 and the according Vision Toolkit will only run with the Vision runtime 8.6 anymore). This was not really a problem a few years ago but nowadays installing a new version of LabVIEW has many chances to (and usually will) update a lot of things that affect earlier installed LabVIEW versions. So be careful and I definitely won't install a Beta version on my development machine anymore. You can best use a virtual machine for that (or even better since the VmWare tends to be a bit sluggish on my notebook do it on a completely different machine instead, that you can wipe afterward.) For the time being running Betas has been because of that a major hassle so I have done little Beta work with the latest two or three LabVIEW versions. Rolf Kalbermatter Quote Link to comment
Ton Plomp Posted October 1, 2009 Report Share Posted October 1, 2009 What I have done in the recent betas (8.6 and 9.0) is testing my own tools that I (daily) use, and look at the discussions in the beta forum. Also checking out some of the new features is something to doe. I don't have a set of tests/code that I use for evaluating the beta. Hopefully NI has allready sifted out the biggest misses, however we all know they can't cover everything. I have hardly seen issues like Rolf describes them but if I understand it correctly recent versions of toolkits will be better multi-version ready. Ton Quote Link to comment
Rolf Kalbermatter Posted October 1, 2009 Report Share Posted October 1, 2009 What I have done in the recent betas (8.6 and 9.0) is testing my own tools that I (daily) use, and look at the discussions in the beta forum. Also checking out some of the new features is something to doe. I don't have a set of tests/code that I use for evaluating the beta. Hopefully NI has allready sifted out the biggest misses, however we all know they can't cover everything. I have hardly seen issues like Rolf describes them but if I understand it correctly recent versions of toolkits will be better multi-version ready. Ton Yes the Toolkits in 8.6 should have been like that already, though I think there has been a slip here and there. But the Vision Module is unfortunately not a Toolkit in the sense that it is not maintained by the LabVIEW group but by a seperate development group and they did not seem to be able to get the installer adjusted to be more friendly to earlier versions. Rolf Kalbermatter Quote Link to comment
pallen Posted October 2, 2009 Report Share Posted October 2, 2009 For those that do participate in the beta, how do you minimize risk to your projects while still adequately testing Labview's new beta functions? I've participated in a couple of betas. Typically I'll only install the LV beta on my home PC. Although now that I have a shiny new laptop with a BIG hard drive, I've got it all chopped up into slices for different operating systems. This way even if I do install on my work machine, I'm not risking my current installations of LabVIEW. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.