Everyone stop upgrading, dammit!


We're starting to feel the pressure to upgrade from 2001Plus to the latest version. We have a couple of customers that have upgraded so we can no longer work directly with their files unless they send us dumb parasolids.

So I'm hereby requesting that every SW customer out there stops upgrading from now on. We'll bite the bullet and upgrade to 2004Plus but that's it. No more.


Ah, well it was worth a shot. Maybe I'll have better luck with MS Office customers.

Joel Moore

Reply to
Joel Moore
Loading thread data ...

Ahhh... No! I don't think soo!


Regards, Scott

Reply to

I'm sure SolidWorks or whatever would be glad to stop *making us upgrade*...as long as we kept paying maintenance every year.


Reply to

Upgrading would not be a problem for anyone if the file formats didn't keep changing. I remember a number of other cad system who would keep thier formats the same for a number of years. Of course, nothing much ever seemed to change in these other Cad packages either.


Reply to

Do you remember any _parametric 3D-CAD_ that has kept the format for several years?

Reply to
Markku Lehtola

I could (& have in the past) written a lengthy bit on virtually mandatory upgrades, but I'm going to just summarize my (& mine only) opinion on this (20 years in CAD & 40 in design).

  1. God did not have an eleventh commandment that software must be upgraded every 365 days (ohhh...well maybe he did if God is the CFO of Swks).
  2. End users should have software that is as flexible as possible for routine bi-directional communication (as not everyone can afford the man hours to upgrade & train every year).
  3. End users have limited amount of time for both debugging, upgrade relearning/training (other things than Swks need attention, too, no thanks to MS).
  4. Productive End Users do NOT have time to serve as paying Beta Customers on a virtually mandatory paid upgrade program (I never start working on a new Swks release until Service Pack 2-4).
  5. I'll be willing to bet the best Mexican food meal in town (because if I loose, at lease I'll enjoy something) that the CEO & CFO of SolidWorks do not use and upgrade and learn on their own each new SWks release & subsequent Service Packs, or they would quickly go nuts and seek a 2 year upgrade program.


Reply to
Bo Clawson

Actually ProE had some capability to do this when their model files were man readable. It was a simple edit to the file that made this possible.

Markku Lehtola wrote:

Reply to

I think this has been discussed in one way or another, and I think one of the major questions that kept coming up was, how would one go about implemeting what is new to be represented in the old? (ie multi-bodies) And that is something that is kind of an easy solution. (ie has to come back to a previous version as an assebly, possibly) But there are some very much more complex operations that would require SW to code to complete this. And as it is we are having too many problems with the code as it is (ie crashing, bugs, what have you).

Another question I would ask is, how far do you go back? What is the cut off for how many years that backwards compatability is supported? As it is, SW as program is weighing more and more (as in the programs size).

I am not defending SW by any means. I am just pointing out some things that I know would become major issues. Could they do code now so that they can go backwards for the future...who knows. One thing about the future is that you never know what new and improved thing that you will be implementing.

Idunno, My 2cents

Reply to
Arthur Y-S

We could be content to lose features that aren't supported in that release. That's how Acad does it. That could be improved on by warning the user of the incompatable feature before performing the export. Then you'd have the option to fix it, export it as an imported feature body, or a dumb solid for versions prior to 03.

The only problem here would be features that solve differently in different releases. Not that this current behavior is acceptable. Plenty of examples have been given here of that.

Reply to
Dale Dunn

Makes me think of HTML. Even though browser developers often added "enhancements" that introduced unsupported HTML elements, for the most part you could trust that web pages would display properly in any well- designed browser as long as you stuck to the core HTML standard. Revisions to the HTML standard are not taken lightly.

There are also thousands of XML-based formats being developed out there that are designed to promote cross-application compatibility. Could something like this work for CAD data?

One problem with this is that CAD developers would obviously feel constrained by a rigid, open-source data format. It would make it difficult for them to add features to their software that give them a competitive edge. So it would be up to customers to let them know that adherence to a common file format is more important than gee-whiz enhancements.

A second problem is that there are current format standards that haven't really done any good. Any CAD package worth its salt supports IGES, DXF, and probably STEP yet there are often issues with working with these formats. Why? Are the formats flawed? Are the software developers just lax in implementing them? Maybe there should be some sort of certification that tests a program's ability to handle these formats.

Maybe someday someone will develop a killer CAD app, release the native format to the control of some standards body, and then other CAD companies will have no choice but to support it or suffer.

Joel Moore

"Jay" wrote in news:kgIwb.298486$HS4.2684748@attbi_s01:

Reply to
Joel Moore

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.