All service packs should be useable for the version you own, regardless of your SSP status. Currently, service packs are only good if you have a SSP active or had enough forethought to buy it in the middle of the year between versions.
I agree wholeheartedly that if you buy LV 201x, then 201x SP1 MUST be available when released. Otherwise all of the promises NI has made int he last few years about improving stability are really just a bad joke.
Please correct me if I'm wrong, but I think that what Intaris requests be true already is true.
If you buy LabVIEW 2013, it comes with a 1 year SSP. That SSP guarantees that you get 2013 SP1 because we only the current version of LabVIEW. You can't get 2013 after 2014 comes out.
The one-year SSP also guarantees that you get 2014 when it comes out. What it does not guarantee is that you will also get 2014 SP1. You have to renew to continue getting updates.
So, if you buy 20XX, you are guaranteed to get 20XX SP1.
You also get 20XX+1 for free, but you are not guaranteed to get 20XX+1 SP1 for free. Somewhere in there you have to renew your SSP.
What we see annually is that some people buy LV around this time of year. The lucky ones get LVx SP1, LVx+1 and LVx+1 SP1. The unlucky ones get LVx, LVx SP1 (soon thereafter) and LVx+1. You may argue that the latter group should be happy to preview LVx+1, but my empirical evidence is that many do not see it that way. I do not buy the getting LVx+1 "for free" argument, its value is included in the price and part of the decision everyone should make about whether that price is fair.
I think the spirit of this idea is that Service Packs become a part of long-term suppport of a LV version, not some new product release. If you own LVx you should be able to update to LVx SP1. Marketing can decide how to deal with it, either tie a SSP to specific releases (LVx and LVx SP1) or basically keep it tied to a specific timeframe and perhaps allow some users one more "release" than they would get under the current system.
The angst with the current system is real and palpable (especially this time of year). Sometimes we get stuck in the middle, by reccommending NI software we are de facto condoning this behavior. "You're the one that told us to buy this" I either have to tap dance, explain how to game the system, or suggest alternatives.
I see a product like the SSP as "a cheaper way to stay current", as in a "I obtain a discount by perpetually buying into the version flow".
But I don't see Service Packs as more than accumulated bug fixes, and I don't expect to have to accept any bugs in the LV version I purchase. It's a huge stick up my behind when I pay for something and have to pay again to get a fault in the product fixed. A fault that a) was in the product when I bought it, b) is acknowledged by the manufacturer (NI) as a fault, c) has an implemented fix available.
It's a downward spiral that products ship with "known defects" that you aren't guarenteed to get a fix for, even when such a fix exists. Sure, if a bug exists that is too expensive to fix or has too little an audience to make a fix viable, then so be it. But when a bug fix is deemed important enough to be in a Service Pack, then all affected users should get that bug fix for free.
Currently it's up to the whim of NI to categorize a fix as critical (patch is free to download) or not critical (SP1 costs money). I have software that does not work correctly due to known bugs, but where the bug fixes aren't "critical" but contained in a Service Pack. For my application such an "un-critical" bug fix might be critical.
If I buy LVxxxx then every fix ever released for LVxxxx should be free for me. When I buy into the SSP, then I'll continue to be able to download LVxxxx, LVxxxx+1, LVxxxx+2 etc as long as I maintain my SSP. That's how it should be.
The real problem is due to "where do we stop calling it a bug fix?". LV2013 fixed a number of bugs in LV2012 SP1, but it had to be called LV2013 because it was that time of the year. The only way to keep the customers happy would be to release an LV2012 SP2 (with the bug fixes for LV2012 SP1), and then later an LV2012 SP3 etc. NI would then also release LV2013 with new features over LV2012 and start a new separate branch from there. That LV2013 (and consequently LV2013 SP1, SP2 etc.) would then be a new LV version.
As it is now you can never talk about a stable LV version. LV2012 was never stable, it contains known critical bugs. LV2013 likewise, and so it will continue.
> What happens when you purchase a license of LV in July?
Let's say it is July 2014. You immediately get LV 2013 SP1. You get a free upgrade to LV 2014 and then to LV 2014 SP1. When July 2015 comes around, you either renew or you don't get LV 2015 when it comes out in August.
I don't have to pay for LabVIEW. But I have friends who do, so SSP is a topic that I try to understand even though it doesn't affect me. On the other hand, I am a LabVIEW user and I do have to deal with the upgrade process for my personal projects. I also don't make the business decisions for how we release LabVIEW. But I do hear those decisions being made. I want to try to tie some of those conversations together.
Some of you say you don't upgrade until the SP1 is available. I honestly cannot tell the difference. The probability of having trouble when I upgrade, particularly for the last 4 versions of LabVIEW, is about equal between upgrading from the release to the service pack as from the service pack to the next release. As Steen correctly points out, a bug might not be critical from an overall standpoint, but for my app, it might be absolutely vital. So a minor bug in an SP1 may be just as bad as a critical one in an August release. Luckily, for the last four versions of LabVIEW, the probability of having problems on upgrade -- for me -- has been very small. Everyone's miliage varies, because of the aforementioned point about which bugs are critical.
If the directories just installed one over the top of the other instead of coming down along side, I wouldn't really be able to tell the difference. We have put new features in service packs. We have added bugs accidentally in service packs. About the only thing we can't do in a service pack is change the binary entry points of the run time engine.
I hate to poke holes in an effective shell game, but... suppose instead of "LV 2013 SP1" and "LV 2014", we changed the names of the releases to "LV 2014 Spring" and "LV 2014 Summer". I'm not sure I would notice, and I'm pretty sure there's a block of customers that would say, "Well, I always wait for the Summer release when things are stabilized."
What does all this have to do with the SSP? Well, I see LabVIEW as releasing twice per year, and your SSP gets you two full upgrades (see my previous answer to what happens if you buy in July). LV 2013 SP1 is a bug fix for LV 2013 to the exact same degree that LV 2014 is a bug fix for LV 2013 SP1. At best, they are smaller releases. But they are not patches.
The bugs that we judge to be critical to those not upgrading do go in patches. Steen is totally correct about the classification of the bugs being our judgement call. We don't fix everything in a patch because patches do absolutely nothing more than fix the bug. And we fix those on a case-by-case basis because it is financially infeasible to do otherwise. I have seen bugs reported that go back to LV 5.0. We aren't going to dig out the machines to rebuild LV 5.0. Oh, we could if paid enough money, but it is hard maintaining the build machines that we do have going back three versions. And the code has shifted enough that often the older versions need unique patches, or cannot apply mutation resulting in hacks that get the job done.
Given all of that, I have a hard time seeing where the SSP is being unfair (and, therefore, cannot see how it could be made more fair). Once a year we ask you to pay to keep getting new versions. We guarantee that you get at least one version labeled "SP1" for those of you who think that is more stable. Those who buy between March and July get two such SP1 versions -- lucky, but doesn't seem to me to count against those who buy at other times.
Should we change it such that all SSPs expire in April of the year following whenever you purchase? Because that sounds like about the only change that would make it work out from the comments in the forums here.
I stick to separate fixes from anything else. If I buy LabVIEW XXXX, I would like to know that for a time frame of X years (or until date XX/XX/XXXX) NI will regularly fix it to achieve the stability we all need, no new features.
Once NI ties fixes and new features (new versions) you always receive bug fixes with new features and it's new bugs!
Maybe is too much release a new version every year, or twice, considering SSP (Spring & Summer).
