Revert to old LabVIEW version naming

[Darin.K]

Now that my LV version is so "last year" I would just like to state my preference for the original naming scheme with simple version numbers.  If it seems too boring, you can go to Roman numerals, I'd purchase LabVIEW X. 

Of what has been tried recently: 6i, 7 Express, 8.20, and 2009 I prefer the simple naming to all of them.

[Mads]

The naming scheme (or lack thereof) is probably decided by the marketing department...

I agree with you - stick to the Major.Minor.Fix - Build scheme.

(If you don't think that's fancy enough - start by renaming LabVIEW to something without the word "Lab" in it instead 😉  )

[muks]

But now we get labVIEW every year and we know the version and the corresponding year are same. Can someone tell me when was labview 6 released?

Frankly i dont see any advantages of the naming it 2009 other than ni forcing themself to release a new version every year. which can actually be good............

[Spectre_Dave]

The downside of releasing every year is the initial release of LabVIEW tends to be more bug-ridden than when LabVIEW was not released on a yearly schedule.

[muks]

True true...

[Mads]

New version every year because of the name is probably not guaranteed. Seen Windows 2001 or 2002?

I do not think pushing new releases every year would be all good either - it might make more of the changes incremental instead of major/revolutional. Just the logistics of a repeated release would tie up lots of resources at NI as well, resources better spent on actually making better products.

Most importantly for me though is tha fact that upgrading to new versions is a lot of work for the customers; you have the installation and recompilations with possible changes...and you have the fact that the run-time is normally upgraded as well. Keeping plug-ins compatible with new builds of the same software e.g. is plenty of work for us....I would rather see major upgrades every 2-3 years than minor upgrades every year.

[AristosQueue (NI)]

We've had a release every single year since 2005. We didn't move to this naming system without establishing a trackrecord and feeling confident that we could hit a release every year. Further, our general bug rate (except for the 2005 release) is lower under this system -- whether that's causation or just correlation is unknown, but it has definitely not caused an uptick in bugs. My personal theory: under the previous system, a release would hold until all features were ready, putting pressure on some features to declare themselves done when they still had bugs so that the release could happen. Under the new system, a release happens and the features that are ready go out and those that aren't ready hold for the next year. Thus it is rarer for any single feature to hold up the whole release train, so there's less pressure to release before everything is ready. Just my theory. Nothing but annecdotes to back it up.

LV 2010 is proceeding right on schedule.

[AristosQueue (NI)]

> The downside of releasing every year is the initial release of LabVIEW tends to be more

> bug-ridden than when LabVIEW was not released on a yearly schedule.

Any perception that the releases are more bug ridden is probably due much more to our reporting to the general public of our known bugs.  We didn't used to share that information. If you're more aware of the problems, you may long for the old days, but I put this in the same category as Russians who long for the old days of communism "when planes never ever crashed." 😉

[falkpl]

Let the programmers (major.minor.fix.build) name the release not marketing.  I spend too much time explaning the versioning to my clients.  If we want to choose random naming schemes I think the next version should be "Labview so 2000 and late" or Labview 2009++.

(Really Labview 9.1 works for me).

[AristosQueue (NI)]

The numeric version number still exists and is still posted on the splash screen and about box. We were happy about the fact that our previous version number and the year lined up well for this transition. 9.0.0.0 was released in August 2009. In early 2010, we'll release 9.0.1.0. In August of this year, we'll have 10.0.0.0.

[Darin.K]

Mostly I am stating a basic preference, but if I think about it too much a few things start to bug me.  I guess that marketing must be involved, and as far as they are concerned they have boated this bass so I am not the target audience for their naming schemes.  (Sadly they are right).  What they are doing, however, is changing the rules that an old-timer like myself has grown used to.

>We've had a release every single year since 2005.

Personally, I view an 8.2 - 8.5 or 8.5-8.6 much differently than 8.x -> 9.0 transition. (Who decides what the increment is BTW?)  Now should we lower our expectations for what a new version entails.  Or is some years a super-duper upgrade and others a really super-duper upgrade.  Over the first twenty years there were 8 major versions, one every 2.5 years or so.  Not bad, having used almost every version released I have come to notice a few things:  The x.0 versions tend to have some nice new features, but in most cases there were surprises lurking.  Most kinks were worked out in the x.1 and later versions.  (I like 7.1 better than 8.0 and 8.6 slightly better than 9.0 overall).  Working through the kinks in the new features of 9.0 (snippets and 3D graphs come to mind), fixing some long-standing bugs and requested modifications and producing a solid v9.1 (or 9.2 or 9.5) would be very nice.  My fear is that version 10.0 will be filled with more very intriguing, but not-quite ready features just to fill some quota of "new features", and the nuts-and-bolts things we've wanted fixed for a long time will be pushed back again.  There will be a lot of cool new things for me to Quick Drop, but I will probably still have to wait an eternity for it to start.