Useless

[Peter De Vlieger]

(rant mode on)
So today I got notified that once again an error that has been returning time and time again for more than a decade will once again be fixed in 2023SP1

Woohoo !

To qoute "The following SPR (SolidWorks Performance Report) status has changed to Implemented."

And the automated email ends with the usual standard phrase "DS SolidWorks does not guarantee that this SPR fix will be available in the indicated future release of the product since at this time the SPR fix has not completed QA procedures that incorporate all SPR fixes and enhancements into a new version of our product."

If you can't guarantee it... then what's the use of notifying the customers that it WILL be fixed?

I understand that this bit of legalize is needed for the US market but they really don't see, or don't care, that it makes them look silly to the rest of the world.Think about it, this is the company saying that the error 'might' be resolved (for the time being) because it just might as well be that it's still in the FUBAR stage so that once SP1 comes out the error can just as well still be happening.

Out of experience I know that the latter is not unlikely because I have had it happen in the past that I got notified that certain things would be fixed... until you get your hands on the version that was supposed to have the fix and guess what... it was still broken and it took several more years and more reporting and Rx movies, and emails, and contacting VAR and nagging, to end up with finally a fix..... that stopped working the next SP.

This is a company claiming to be professionals making professional software for professionals. Their QA is a freaking joke.
Good thing we don't have pay them thousands each year per license.... oh wait.

[jcapriotti]

And the automated email ends with the usual standard phrase "DS SolidWorks does not guarantee that this SPR fix will be available in the indicated future release of the product since at this time the SPR fix has not completed QA procedures that incorporate all SPR fixes and enhancements into a new version of our product."

If you can't guarantee it... then what's the use of notifying the customers that it WILL be fixed?

If you read carefully, it states that it is fixed but that QA procedures related to all SPRs in the patch are not done. So a last minute QA issue found might result in them pulling the fix if it's found to break something else. We would do the same internally. Our users know if a fix is coming but we may have to pull it last minute due to a failed test.

Out of experience I know that the latter is not unlikely because I have had it happen in the past that I got notified that certain things would be fixed... until you get your hands on the version that was supposed to have the fix and guess what... it was still broken and it took several more years and more reporting and Rx movies, and emails, and contacting VAR and nagging, to end up with finally a fix..... that stopped working the next SP.

General if the fix makes it into the SP then the issue is fixed.....however......I've seen where they didn't fix all instances of an issue because there was more than one cause and they only fixed one of them. Virtual Components becoming "unvirtual" is a good example, there were many areas and workflows causing it.

I think it comes down to how transparent you want them to be with their process. I supposed they could just say nothing about what fixes are in the upcoming SP until it lands. They elected to be more transparent upfront and let you see what's coming before. Is that better? Guess that's up to you.

[mattpeneguy]

(rant mode on)
So today I got notified that once again an error that has been returning time and time again for more than a decade will once again be fixed in 2023SP1

Woohoo !

To qoute "The following SPR (SolidWorks Performance Report) status has changed to Implemented."

And the automated email ends with the usual standard phrase "DS SolidWorks does not guarantee that this SPR fix will be available in the indicated future release of the product since at this time the SPR fix has not completed QA procedures that incorporate all SPR fixes and enhancements into a new version of our product."

If you can't guarantee it... then what's the use of notifying the customers that it WILL be fixed?

I understand that this bit of legalize is needed for the US market but they really don't see, or don't care, that it makes them look silly to the rest of the world.Think about it, this is the company saying that the error 'might' be resolved (for the time being) because it just might as well be that it's still in the FUBAR stage so that once SP1 comes out the error can just as well still be happening.

Out of experience I know that the latter is not unlikely because I have had it happen in the past that I got notified that certain things would be fixed... until you get your hands on the version that was supposed to have the fix and guess what... it was still broken and it took several more years and more reporting and Rx movies, and emails, and contacting VAR and nagging, to end up with finally a fix..... that stopped working the next SP.

This is a company claiming to be professionals making professional software for professionals. Their QA is a freaking joke.
Good thing we don't have pay them thousands each year per license.... oh wait.

You obviously misunderstand your role...You are part of the QA team...

[Peter De Vlieger]

I think it comes down to how transparent you want them to be with their process.

I'm stunned how you can claim them being transparent.

Imagine taking your car in for some major repairs. After a week you get a call to tell you that it's going to be ready next Tuesday and you can come and pick it up. Tuesday arrives and you go to the shop only to be told that it isn't fixed at all, in fact, it's still in the same broken condition.
Would you call that 'transparent' or would you tear them a new one?

No matter how much you want to spin it in my book it's complete BS.

Either something is fixed or it isn't. There is no use what so ever to announce that perhaps something is going to be fixed when you haven't even ran it past QA to make sure it will be. Sure, accidents happen, people make mistakes but stating something is fixed while you haven't done due diligence tells a lot about the culture in a company, and it stinks.

Heck, I've had it happen that I got the equivalent of an email announcing that something was going to be fixed in 2025 alpha build. WHO the EFF cares if they THINK it MIGHT be fixed in a version that is utterly unavailable to the public for an other few years knowing that there's a good to fair chance that by the time SP0 rolls around that it will be broken and if it isn't then it will be by SP4.

Next time something goes wrong tell your client that it will be all rectified (perhaps..maybe) in 3 years time and if he isn't happy about it then say that you are being transparent, I bet that client is going to be an ex-client pretty darn quickly.

[Peter De Vlieger]

You obviously misunderstand your role...You are part of the QA team...

Nay, I was being silly, i forgot that we the customers are the Beta testers.

[Bradfordzzz]

Nay, I was being silly, i forgot that we the customers are the Beta testers.

image.png (85.17 KiB) Viewed 906 times

[jcapriotti]

I'm stunned how you can claim them being transparent.

They told you it was expected to be fixed in an SP, then followed up with a disclaimer that it could get pulled if an issue was found during the QA process. That is the definition of transparency. The question is whether you rather they not tell you anything until the day the SP drops. You would get different answers depending on who you ask.

Imagine taking your car in for some major repairs. After a week you get a call to tell you that it's going to be ready next Tuesday and you can come and pick it up. Tuesday arrives and you go to the shop only to be told that it isn't fixed at all, in fact, it's still in the same broken condition.

Funny you mentioned that as I have had that happen. Just had my engine replaced under recall. They called to tell me they started the work and it would take a few days. I called a few days later and they said it would likely be ready on Friday. Then they called me Thursday to tell me it wouldn't be ready as the clutch cable broke when they test drove it. They would get the part and have it ready Monday morning. I went to pick up Monday and the 02 sensor went bad and threw a code, had to come back that afternoon. Frustrating yes...maybe they shouldn't have told me any date and time.....most customers at least want to know when to expect it though.

[Frederick_Law]

DS will fix it faster if you can reproduce the problem in current Beta.
After that they don't give a @#$%.

[dave.laban]

They told you it was expected to be fixed in an SP, then followed up with a disclaimer that it could get pulled if an issue was found during the QA process. That is the definition of transparency. The question is whether you rather they not tell you anything until the day the SP drops. You would get different answers depending on who you ask.

Is QA happening right until the last second before the SP is released though? I think what Peter is saying is that there's no point sending the "it's fixed" message until they've done all the testing they need to do, rather than the current "it's fixed unless testing tells us it isn't".

[jcapriotti]

Is QA happening right until the last second before the SP is released though? I think what Peter is saying is that there's no point sending the "it's fixed" message until they've done all the testing they need to do, rather than the current "it's fixed unless testing tells us it isn't".

I imagine there are several layers of QA going right up into release. Again, it's what level of notification do you want them to give, maybe we should have an option on our account? Personally, I'd like more information than they give, like SPR 000000 you submitted is currently planned for 2023 sp3.

[AlexLachance]

I imagine there are several layers of QA going right up into release. Again, it's what level of notification do you want them to give, maybe we should have an option on our account? Personally, I'd like more information than they give, like SPR 000000 you submitted is currently planned for 2023 sp3.

You should have that info. If you don't, then it simply isn't assigned.

Even that info could be understandable of being wrong, since it's a projection. An e-mail though, notifying that a SPR has been fixed, when it isn't confirmed that it has been, is rather oblivious.

[Frederick_Law]

Just like IT reply and close the ticket before you can reply LOL

[jcapriotti]

You should have that info. If you don't, then it simply isn't assigned.

Even that info could be understandable of being wrong, since it's a projection. An e-mail though, notifying that a SPR has been fixed, when it isn't confirmed that it has been, is rather oblivious.

I've never seen they are working on an SPR far a head of time. Unless I search the knowledge base for the SPR, sometimes you can see it's in the next version in an alpha build (2024 a1) or beta if further along (2024 b1). I've never seen one being worked on in a service pack or any indicator that it is until the SP is near complete.

[AlexLachance]

I've never seen they are working on an SPR far a head of time. Unless I search the knowledge base for the SPR, sometimes you can see it's in the next version in an alpha build (2024 a1) or beta if further along (2024 b1). I've never seen one being worked on in a service pack or any indicator that it is until the SP is near complete.

I haven't logged SPR's since 2019 but when I did, if they were associated to the "major" SPR, when they start working on fixing it, there's a projection made on it. I've seen it change a few times but never to skip entire years. I've seen SPR's not get associated and get lost in the big bag of no-hit SPR's and never get an update either. Generally, it's dependant on the VAR's "talents" to find existing SPR's that relate to your issues.

It's generally wrote in the "Status" section. Notice how many high impacts aren't fixed.

Edit: It's also funny cause there are bugs that I reported in 2019 that they say were fixed in 2017

[bnemec]

I like to subscribe to the mailing list on the dev branch that's working on the change.

Oh wait. Never mind...