Skip to main content
L
LawrenceS18-Opal
18-Opal
February 3, 2022
Solved

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

  • February 3, 2022
  • 5 replies
  • 4798 views

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?

Best answer by DomenicLaritz

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.

5 replies

DomenicLaritz
DomenicLaritz17-PeridotAnswer
17-Peridot
February 4, 2022

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.

    L
    LawrenceS18-OpalAuthor
    18-Opal
    February 7, 2022

    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
    DomenicLaritz17-Peridot
    17-Peridot
    February 8, 2022

    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
      Chris321-Topaz I
      21-Topaz I
      February 4, 2022

      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)

        B
        23-Emerald III
        BenLoosli23-Emerald III
        23-Emerald III
        February 7, 2022

        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.

        T
        23-Emerald IV
        TomU23-Emerald IV
        23-Emerald IV
        February 8, 2022

        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.

        B
        BrianToussaint19-Tanzanite
        19-Tanzanite
        February 8, 2022

        @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.

        B
        23-Emerald III
        BenLoosli23-Emerald III
        23-Emerald III
        February 8, 2022

        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.

          Terms & ConditionsAccessibility statement