21-Topaz I

Question

Maintenance release

Forum|Forum|12 years ago
January 8, 2014
24 replies
4550 views

I don't know if this has been brought up recently but has anyone noticed that since PDMLink 10.1 has been released a maintenance build has been released every 3 or 4 months...except for the next one (M050). M040 was released April 25, 2013 but M050 will be released Q3 2014. About a year and a half? They must finally be putting some work/thoughts into this next build.

Just a hump-day thought.

Steve G

Other

T

TomU

23-Emerald IV

I think you're looking at this wrong. 10.1 is old. 10.2 is current and I dare say most developers are either working on later releases of 10.2 or working on 10.3. Maintenance releases for 10.1 will only be released once in a great while to fix really big problems. Based on past history, and what is shown in the product calendar, I doubt 10.1 will go any further than M060.

Tom U.

B

BenLoosli

23-Emerald III

Or it doesn't need any bug fixes (said while biting my tongue to keep from laughing)

J

jessh

12-Amethyst

Not speaking for my employer here, but purely rather purely speculating:

I'd say one cause of such long gaps is those customers which do not
apply use MORs on any sort of timely or frequent basis.

This reduces the benefit to PTC and its customers of bothering to
release MORs in a timely fashion.

It also means that such customers are choosing to suffer from countless
known issues that have already been fixed in later MORs...

--
Jess Holle

S

ScottPearson

1-Visitor

One reason customers do not apply every build that comes along in a "timely" fashion is the time and cost associated with planning and implementing the install of the builds.

Be it PDMLink or Creo, jumping on every build involves testing by the customer.

And there have been cases of bleeding-edge remorse when a build reveals an ugly glitch only a-f-t-e-r a guy has invested time in testing, or worse, after deployment. (The "read-only" glitch of Creo m080 comes to mind.)

Given that software only has one chance to give a first impression, a rushed deployment doesn't help any person's (or vendor's) reputation.

Sometimes "suffering" with an existing issue of modest impact (i.e. staying on current build) is the less distasteful and less costly than jumping into the unknown issues of the latest allegedly fixed build.

Just food for thought if anyone is interested in how things are out here in the real world.

Any similar (or dissimilar) viewpoints?

Scott Pearson
Senior Designer
CAD System Administrator

[cid:image004.png@01CF0C58.001BF000]S O U T H W E S T R E S E A R C H I N S T I T U T E(r)
Space Science and Engineering Division
Space Systems Directorate
Department of Space Engineering
6220 Culebra Road, San Antonio, TX 78238

1_oledata.zip

J

jessh

12-Amethyst

I understand this issue/concern -- and while I don't speak for my
employer, I believe PTC as a whole understands the need for MORs to be
of the utmost quality and regression free nature.

Certainly mistakes have been made in the past. I believe recent MORs
have improved a great deal, but there is always room for improvement.
PTC should continue to focus on this issue -- and customers should
continue to press any MOR quality issues with PTC.

All that said, while I understand not wanting to be on the bleeding
edge, applying MORs to one's production system say 1-4 months after
their introduction (and testing over these months) would still seem like
a best practice one should plan on.

--
Jess Holle

V

vmcdaniel

1-Visitor

Perhaps this is why 10.2 now has new monthly Critical Patch Sets, to address SPR's, and longer timing between MOR's?

J

jessh

12-Amethyst

The CPS delivery vehicle is certainly an attempt to make delivery of
critical updates to customers more efficient and effective -- both for
PTC and its customers.

I believe the intent is that CPS releases for F000 stop shortly after
M010 is released and CPS releases for M010 stop shortly after M020 is
released. Thus this isn't a mechanism for avoiding MORs, but rather
providing much better delivery of important fixes between MOR releases.

J

JoshuaHouser

16-Pearl

I lived on the "bleeding" edge of Pro/E releases for several years with Pro/E and incrementing Pro/Intralink enough to enable the next build of Pro/E. By keeping up with the build releases, it made it easier to validate changes in release, there weren't as many changes from one build to the next. It should also be mentioned that this was managed with a very tight relationship with PTC and usually very early knowledge of the new feature set.

I have witnessed the other strategy of upgrading on a much less regular basis. What I see is that the workload for evaluating that release is much more tedious because of so many more changes.

Joshua Houser

(have I talked to you about FIRST robotics yet?)

Pelco by Schneider Electric

Methods & Tools Sr. Engineer

S

SarahFord

1-Visitor

Personally, it's the cost that keeps us from putting in MOR's.
When I have to pay £1,000 a day for the software guy from my reseller to come in and do the upgrade, I can't justify the expense.
It may be very different for those companies who have people on staff capable of doing the upgrade.

Regards
Sarah Smith
CAD Designer/Admin
Westwind Air Bearings
Tel. 01202 627236

J

jessh

12-Amethyst

I would note that in general as a developer I am able to troubleshoot
issues /far/ more quickly and efficiently and follow far fewer false
trails if they are reported against the latest MOR.

This is because all the issues that have already been fixed can be ruled
out and we can focus on looking for what /else/ might be going wrong.
Also the code is then recent code that developers are familiar with --
rather than some version we haven't seen in years.

Many open source projects pretty much ignore bugs reported against
anything but the latest version of the software for such reasons.

Show more replies

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded