Reflecting on PTC's change of Support and thoughts on when to upgrade?

[LawrenceS]

Previous to Creo4 Release Cycle:

• Actual Build support:
  • Creo2=26 blds
  • Creo3=20 blds

Standard VS Enterprise Release Cycles (Creo4-Creo7) 

• Standard Releases: Creo5 and Creo6
  • Full Support=1 yr (fast build releases)
  • Extended Support=1yr (slow build releases)
  • Total Support=2 yrs
  • Actual Build Support:
    • Creo5=7 blds
    • Creo6=7 blds
• Enterprise Releases: Creo4 & Creo7
  • Full Support=3 yr (fast build releases)
  • Extended Support=1yr (slow build releases)
  • Total Support=4 yrs
  • Actual Build Support
    • Creo4=16 blds
    • Creo7=TBD (est.~15?)

New release support schedule starting with Creo 8.0 

• Full Support=2 yr (fast build releases)
• Extended Support=2yr (slow build releases)
• Total Support=4 yrs
• Actual Build Support
  • Creo8=TBD (est.~13?)
  • Creo9=TBD (est.~13?)

The implication here seem to be fewer builds per 'Enterprise' release of Creo.  Those of us with lots of users to support at our companies know the challenges of upgrading & the testing that goes with it.

Do you have a general rule on when you upgrade to get a stable release (E.g. M060, after 1 yr, etc) and do you think this change from PTC affects when you will consider upgrading?

[DomenicLaritz · Accepted solution]

With Creo 2.0 and earlier, our rule of thumb was to go productive with datacode M100 at the earliest.
This approach had worked well and the maturity level of M100 was actually always quite good.

After Creo 2.0, we upgraded to Creo 4.0 M040.
At that point, Creo 4.0 was a good year old and this version could be used productively in a stable manner.
Nevertheless, we were happy when M060 came out half a year later, because it contained a few bug fixes that were quite relevant for us.
With Creo 4.0, we always used the next but one date code, i.e. M080, M100, M120 and finally M140.

Next, we went live with Creo 7.0.3.0.
Here Creo 7.0 was about 10 months old.
This version felt as stable as Creo 4.0 M040 back then.
However, we then jumped straight to M040 a few weeks after the go-live due to some minor improvements.
Nevertheless, we were happy when 7.0.6.0 was released, because it solved a few annoying problems.

Thus, my recommendation for enterprise companies is to roll out versions that have at least one year of market maturity, if possible.

[LawrenceS]

Thank you both for your answers.  @DomenicLaritz thank you for the historical references & details with your ultimate suggestion.  A year seems to make sense with the current release cycle...although I think we are still going to go to Creo7 even though Creo8 is almost a year old...are you considering a Creo8 upgrade?

[DomenicLaritz]

In my company, there is a large Windchill instance that connects more than 20 sites worldwide to manage CAD data from Creo Parametric as well as Creo Elements/Direct.
In other words, Windchill is our driver, and we generally always use LTS versions here.
As far as the CAD systems are concerned, we must of course then adhere to the compatibility matrix.

Last year, we upgraded from v4.0 to v7.0 at all Creo Parametric sites.
This year, we are about to upgrade Windchill to a new major version.
So we will probably not go to a newer Creo Parametric major version until 2023 rather even 2024.

And if the version is to be a year mature in 2024, it will probably be v10.0 (which will be released in 2023).

[Chris3]

We upgraded to 7.0.3 and there were a few bugs but none production limiting. We will likely use the 3rd release as a benchmark (after testing obviously). We are now on 7.0.6 (just upgraded)

[BenLoosli]

I tend to hold off until a few releases have come out. 

With Creo 4, we went with M080 and at the end did do a second upgrade to m150.

When we went to Windchill 11.1, we also jumped to Creo 7.0.5.0. We use the AFX modules and ModelCheck and almost immediately discovered 2 bugs. When creating parts with AFX, the software would automatically create a dummy drawing of the component, which we did not want. That was fixed by moving the drawing templates to a sub-folder. The other issue was with ModelCheck and Validate on. The files would pass MC checks but still fail to check in. PTC fixed both of these in high priority SPRs released with 7.0.7.0. I have upgraded to 7.0.7.0 and the issue seems to be fixed, but we did find that your workspace had to be created in 7.0.7.0 or you could still get the check-in failures.

With that said, being the administrator, I do load other releases for testing before putting a release out to the server for all users. We use a single network mounted load point with a launch script so I only have 1 copy of Creo out there for all users and the script allows me to control which version on Creo they get. I have 2 groups of users and one group is still on Creo 4, but they use the same launch program.

As to production use of initial releases or 1st or 2nd upgrade, I am glad that there are some brave souls (and companies) out there who load them right away and report bugs to PTC and hopeful that PTC will fix them in a quick manner.

[TomU]

We're fairly small (21 Creo licenses) and also run Creo from a shared network location like @BenLoosli.  For that reason I tend to deploy each new maintenance build within a couple of days of release.  If I find some problem, I just change a line in our startup script and everyone is immediately back to running the previous build.

We ran into significant crashing problems with 7.0.5.0 and 7.0.6.0 almost immediately and were forced to stay on 7.0.4.0 until 7.0.7.0 came out.  So far no problems with 7.0.7.0.

[BrianToussaint]

@BenLoosli @TomU I really like using one network installation, but how do you handle VPN's and the general slowness of them?  In the past I had used one network location but when "work at homes" came, I had to move the installation to each machine.  If you have any ideas on how to handle this, that would be great.

[BenLoosli]

I suppose a lot of that depends on how you do your work from home.

We use Remote Desktop Connection so Creo is running on our work desktop workstations, just the display data is transmitted through the VPN/Internet connection.

If you are dealing with laptops and connecting to a corporate server for licenses and the code, I can see issues with latency causing a lot of pain and slowness. Where I used to work, we put workstation laptops to the group managers and loaded software locally with individual licenses so they could work anywhere. Lots of extra licenses, but at the time we had a corporate pool of almost 500 licenses, so easy to get a dozen assigned to individuals. Here, I only have 16 licenses split between 3 license servers, can't afford to tie one license up to 1 person.

[TomU]

Ditto to what @BenLoosli said.  When our users work from home over the VPN, they simply use remote desktop (from whatever they have at home) to connect back to their engineering workstation in the office.  A couple of times during the pandemic I had uses take their engineering workstations home thinking that would let them run Creo only to find out Creo is not actually installed.  Running Creo from the network across the VPN is possible, but ridiculously slow.  In those cases I either installed Creo locally for them or told them to take their workstations back to the office and bring something else home for remote desktop purposes (laptop, etc.).