- It's immediately obvious how old of a LabVIEW version we're dealing with. As it is now, I can't even remember what year LabVIEW 7.0 released (I just looked it up...2003 apparently).
- We become more consistent with other software out there that is moving toward year-based versioning.
- Most toolkits will also be adopting the year-based versioning. So now we don't have to remember that Report Generation Toolkit 1.1.3 only works with LabVIEW 8.6, or that VI Analyzer Toolkit 1.1 only works with LabVIEW 8.0, 8.2, and 8.5. Going forward, Report Generation Toolkit 2009 will work with LabVIEW 2009, VI Analyzer Toolkit 2010 will work with LabVIEW 2010, etc.
- The internal version of VIs saved in LabVIEW 2009 will be 9.0. So it's pretty convenient that the year '2009' lined up with that.
- This one is minor, but up to this point, we always had a code name for LabVIEW releases in R&D. 8.6 was Saturn, 9.0 is Orion. (Again, not a big secret here...I figure if one of our VPs can talk about the code names, so can I). So when you'd talk to somebody about the release, half the time they'd use the code name, and half the time they'd use the version. Now we'll just be referring to each version by the year of its release...no more code names. Trivia question: Any non-NIers out there know the code names for prior LabVIEW releases?
- We won't be using this versioning scheme for drivers. Again, I think this makes sense, because a lot of drivers release multiple times per year. Plus, I don't think I've seen any other driver developers out there use year based versioning. It appears to be primarily for application software.
- I've noticed that people have interpreted LabVIEW version numbers in very different ways over the years. Some people think "x.0" releases are unstable and won't touch them. They prefer to wait for the much more 'stable' "x.1" release. Other people think "x.0" releases are the only ones that have any worthwhile new features, and the "x.1" releases are only 'minor updates'. Truth is, every LabVIEW release (barring x.y.z maintenance releases) is a major release. I've found must-have features in every LabVIEW version since I started programming LabVIEW. I think year-based versioning will help us all gain a more unified vision of what to expect out of a yearly LabVIEW release.
Monday, May 4, 2009
2009 Reasons I Love the New LabVIEW Versioning Scheme
Ok...maybe I don't have *quite* 2009 reasons, but I am a big fan. In case you hadn't heard, the next version of LabVIEW will be LabVIEW 2009. This wasn't a big secret or anything...the new versioning scheme was revealed when we announced the beta. Going forward, each LabVIEW release will simply be versioned based on the year of its release. In no particular order, here's why I like this idea:
Subscribe to:
Post Comments (Atom)
Darren,
ReplyDeleteI like the sound of LabVIEW 2009 (contemporary, fresh, different). I get the feeling I stand alone on this, but aside from knowing what year a version was released, for folks outside NI, isn't this naming scheme losing rather not gaining? I don't like dissenters either, but you did ask :)
"It's immediately obvious how old of a LabVIEW version we're dealing with"
True. That might be handy.
"other software out there ... moving toward year-based versioning"
It is good to follow the crowd sometimes; I like standards :) In this case, the crowd doesn't always release every year. SQL Server 2005 was followed by SQL Server 2008, so while it's year based, the Major release number spans multiple years. Major release attributes are, therefore, retained. Windows moved away from year based naming.
"Most toolkits will also be adopting the year-based versioning"
In your example, if NI had used name-based versions, would LabVIEW 2005, 2006, and 2007 have all used different versions of VI Analyzer, even though it was the same version? In the case of Report Generation, are folks going to have to now buy an upgrade when they upgrade LabVIEW?
"internal version of VIs saved in LabVIEW 2009 will be 9.0"
Internal benefit
"we'll just be referring to each version by the year of its release...no more code names"
Internal benefit
"We won't be using this versioning scheme for drivers"
OK
"year-based versioning will help us all gain a more unified vision of what to expect"
Hiding x.0 releases from the skeptical and x.1 releases from the expectant is still hiding (losing not gaining). Adding Project, Project Libraries, Project Targets, etc. with 8.0 (LabVIEW 2005) is not comparable to auto-populating folders in 8.5 (LabVIEW 2007) or quick-drop, although beloved, in 8.6 (LabVIEW 2008). As I said in the forums, the Major release number helps group common features, KB's, etc, and Major.Minor.Bug logically groups Major, Minor, and Bug fix developments.
That said, it's only a name, and it does sound nice.
-Jason
Jason: Thanks for the all the feedback. I'll address the easiest first:
ReplyDelete"Internal benefit": I work in LabVIEW R&D, and this blog is about my job, so I think it's fair for me to list 'internal benefits'. :)
"Other software out there": Microsoft moved away from year-based versioning for their OSes, but not their application software. Office, Visual Studio, SQL Server, and many more are all on a year-based versioning scheme now, to my knowledge.
Toolkits: You can double-check with your sales guy, but it's my understanding that, going forward, once you buy a LabVIEW toolkit, it's yours for each LabVIEW upgrade you purchase in the future. Some years we'll include new features in toolkits, and some years we may just fix bugs. So if my understanding is true, you don't have to worry about missing out on features, or paying only for bug fixes. Note: I think there are a few toolkits (not sure which ones) that are not adopting LabVIEW's new versioning scheme, so they would be exempt from the policy I just stated (if it is, in fact, correct in the first place).
"unified vision": I don't think we're hiding anything...I think we're closing a gap in communication with customers. Sure, LabVIEW 8.0 was a "major" release with all the project features. LabVIEW 7.1 didn't have as many marketing-friendly new features (can we give Radio Button Controls some love here?), but I've heard many, many customers cite it as the most stable LabVIEW release in recent memory...was that stability considered a "major" feature for them? What about LabVIEW 6.1? It was an x.1 release...so nothing huge right? I'd say fans of the Event Structure and the Auto Tool would heartily disagree. My point here is that, going forward, we no longer have this potentially false dichotomy between x.0 and x.1 versions that may give some people completely different impressions for the same release.
Yes, and I am the curmudgeon who things that there are 2010 reasons not to do this. The push to release on the yearly schedule even if a release is not ready will lead to problematic software.
ReplyDeleteKeeping version numbers for associated packages in synch is good, but that doesn't require
Knowing what year a release came out is fine for LV historians, but know what features were added/dropped is the real useful piece of data.
Why does adopting the naming system of other software houses make much difference. Unless you are going to establish compatibility between like years for other products which seems really unlikely it is just marketing BS. MS has gone from Win 2K back to version 7. Go figure.
The versioning system is like we think. The x.y.0 releases add major features. The x.y.1 are more stable though there have been a few notable exceptions over the years. Actually NI has been way too free with changing the first digit "x", many of the updates over the years were updates and not complete rewrites such as going from interpretive LV to compiled LV code.
The only communication here is that you are expecting a constant revenue stream from yearly releases so that budgeting and marketing are easier. NI will ship a new release in August either by stripping non-working features or shipping with problems. This rigid schedule is good for bus lines, but not software or wine.
Jupiter, Saturn, Orion, Andromeda
Actually you can get a lot of code names whenever LV throws a warning and crashes. It gives a path to the source file and for some packages (ie NI-DAQmx Base) it gives the code name in the path.
Thanks for the feedback. It seems your main issue is the yearly release cycle for LabVIEW. I certainly agree that there are some potentially negative consequences of a yearly release cycle, but that's the decision that NI has made, and it doesn't look like there are any plans to change that. Taking the yearly release as a given, I think year-based versioning makes perfect sense, and that's the opinion I was trying to convey in this blog post.
ReplyDeleteAnd you are correct for the code names of 8.5 (Jupiter), 8.6 (Saturn), 9.0 (Orion), and 2010 (Andromeda). Anybody want to venture some guesses for the code names of the 7.0, 7.1, 8.0, and 8.2 releases?
Hi we are a small company that has been advised to buy labview so that a certain machine we have can be run using labview programming. our dilema is that we can buy two versions of labview from local software suppliers one is labview basic and the other is labview pro....the difference in price is 850 uk pounds against 3.5K uk pounds.
ReplyDeletenot being experts on this can anyone shed light on the extras that we will get for this higher cost. the program needs to run data logging and turn the machine on and off with variable speed all via a NI USB interface card.
You can check out the differences between the development systems here:
ReplyDeletehttp://www.ni.com/labview/how_to_buy.htm
You'll probably want to talk to your local sales rep about the details of your app, but from what little you've mentioned here, the Base version of LabVIEW would probably suit your purposes, assuming you're not doing any advanced signal analysis of your logged data.
Also, in the future, the NI Forums ( http://forums.ni.com ) would probably get you a wider, more appropriate audience for your question than a comment on a mostly-unrelated blog post about LabVIEW version numbering schemes. :)
thank you very much for your help we will look into this further, it could be that you have answered our question already.
ReplyDeleteHi,
ReplyDeletesorry to be a pest, would we be able to produce exe files in the basic labview? and would feedback control be possible in basic labview? these are two of the things that we have been told we would need, but, being complete beginners we don't know who to ask, seems that forums are a bit to advanced for us.
You need the Application Builder to build EXEs out of LabVIEW VIs...it comes with the Professional version, or you can purchase it separately for the Base or Full versions.
ReplyDeleteI don't know much about control systems...I recommend you post specifics about your requirements on the NI Forums to see what other users think would be your best solution.
Once again many thanks for your help, being a small company and with the current economic climate we are having to be extra careful when it comes to spending and your help is much appreciated.
ReplyDeletethankyou.
http://technologizer.com/2009/07/14/version-numbers/1/
ReplyDeleteAs a software developer myself, I really like sequential numbers instead of years or names. Use codename if you need, but keep the numbers!
I just skimmed the first page, but that looks like a really interesting article. I'll try to find some time soon to read it.
ReplyDeleteThe LabVIEW 2009 about dialog says "Version 9.0". Will LabVIEW 2010 be version 9.1 or 10.0? If it could be 9.1, then this is the equivalent of version 6.0.2 being called 6i, and my comments above are sort of moot.
ReplyDeleteAlso, just got a chance to play around with LV 2009, and I wanted to personally thank you for:
Quick Drop Ctrl-D (Create Controls & Indicators for selection)
Quick Drop Ctrl-R (Remove selected code and rewire pass throughs)
Probes window is pretty sweet too.
-Jason
Do you know whether LabVIEW 2010 will be version 9.1 or 10.0?
ReplyDeleteSorry, I don't know what the internal version of LabVIEW 2010 will be.
ReplyDeleteLabVIEW 2009 = 9.0
ReplyDeleteLabVIEW 2009 SP1 = 9.1
LabVIEW 2010 = 10.0
LabVIEW 2010 SP1 = 10.1 (assumption)
@Jason: The LabVIEW 2009 SP1 version is "9.0.1" and I assume that LabVIEW 2010 SP1 will be named similarly.
ReplyDelete