Maintenance release

[STEVEG]

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

[TomU]

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.

[BenLoosli]

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

[jessh]

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

[ScottPearson]

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

[jessh]

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

[vmcdaniel]

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

[jessh]

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.

[JoshuaHouser]

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

[SarahFord]

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

[jessh]

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.

[STEVEG]

As has already been mentioned though, for those of us that use a company to monitor our PDMLink installation and do the upgrades it would be much more costly for each build upgrade.

Steve G

[patrickchin2000]

Hi All,

Regardless of whether it is ProE or Windchill, there should be a PTC supplied JMeter automated script (currently supported by GSO) to test builds of ProE (like World Car or customer data) and Windchill to go through all/most of the OOTB functionality of the World Car or renamed customer data (ptc-edc*). Thus both performance and OOTB issues with the build can be compared to the previuos recorded baseline. Thus, you can validate you system (mirrored or production) before you release. The script should change much between service packs. I mentioned this to Wil Koler before why isn't this provided by PTC OOTB. This will save so much headaches.

Shouldn't go live until the system is validated with load test and regression test.

That's ITIL's rule or do you do a 80/20.

have a good one,

Patrick

In Reply to Stephen Galayda:

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

[patrickchin2000]

Hi All,

I agree with most people who have replied. As soon as a new branch is released (i.e. 10.2), past history and experience with PTC directs me to go to the new version rather than staying on the existing. 10.1 service packs is released slower than 10.2 because I noticemost SPRs and enhancementsare released and tested on 10.2 first then downwardly applied to 10.1.

Yep, it is a question of how much time/risk can the company afford.This is why the risk should be immediately be knownwith an automated test from PTC. I don't know if JMETER can test ProE. I haven't tried Borland SilkTest against ProE.

Patrick

In Reply to Tom Uminn:

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.

[ddemay]

Jess,

Fairly frustrated right now that many fixes are marked ready for 10.1 M050, but you can't get them without opening a xall for each and requesting a patch. There are some memory leak ones that should ve put into a generic downloadable patch. As PTC handles supporting X-2x series of Windchill, new performance bugs should not be introduced in later MOR's because of X-24/X-26 development in same module areas of functionality. We jumped from M010 to M040 and have had more issues, but stuck without a new MOR. We can not use 10.2.

Perhaps you can forward this concern to who manages these decisions?


- Dave



Sent from my Verizon Wireless 4G LTE Smartphone

[ddemay]

PTC needs a rollback machanism then people would employ greater risk. I can uninstall a lousy interfereing Microsoft patch, but not an MOR

With web apps taking over desktop apps, this has veen not well thought out enough.






Sent from my Verizon Wireless 4G LTE Smartphone

[patrickchin2000]

Hey Dave,

When I was working at the fun company called Comdev great guys like James Deadman, Eugene Stewart, John Smithand Darcy Hodgson, we where allowed to research, architect, play and implement UnionFS andRedHat Linux. I later found a more supported Linux application called AuFS. Architectually, you can install any service pack as a layer ontop of your existing install on a different layer mount. The only problem is this better be on a test database.

You can have a baseline install of Windchill as different mount, then create layered mounts for dev, test and production for different properties and configurations. The same can be done for the vaults. Thus, you don't have to create/use tons of disk for duplicating vaults and Windchill installs. The only duplication is a database.

If the MOR fails just remove the layer of the MOR mount and restore the database. I don't know why people are so afraid of going to Linux. Its so simple once you have it installed and you have no Windows issues and constant reboots/restarts. In the end Linux with AuFS saves so much money in disk space and maintenance support.

Regards,

Patrick

[patrickchin2000]

I forgot to mention,

The UnionFS/AuFS mount baseline can be updated at any time by merging or copying over the additional layers to the baselines.

The previous baselines are already archived in backups, once confident, like any code configuration management, reset the baseline mount to a new build/vaulted data.

Cool stuff and not rocket science aye,

Patrick

In Reply to Patrick Chin:

Hey Dave,

When I was working at the fun company called Comdev great guys like James Deadman, Eugene Stewart, John Smithand Darcy Hodgson, we where allowed to research, architect, play and implement UnionFS andRedHat Linux. I later found a more supported Linux application called AuFS. Architectually, you can install any service pack as a layer ontop of your existing install on a different layer mount. The only problem is this better be on a test database.

You can have a baseline install of Windchill as different mount, then create layered mounts for dev, test and production for different properties and configurations. The same can be done for the vaults. Thus, you don't have to create/use tons of disk for duplicating vaults and Windchill installs. The only duplication is a database.

If the MOR fails just remove the layer of the MOR mount and restore the database. I don't know why people are so afraid of going to Linux. Its so simple once you have it installed and you have no Windows issues and constant reboots/restarts. In the end Linux with AuFS saves so much money in disk space and maintenance support.

Regards,

Patrick

[jessh]

Agreed philosophically.

That said, the new MOR may produce data that cannot be read without that
MOR. For instance, data may be serialized to the database which cannot
be read without the MOR in question.

If MORs never created new versions of serializables or new type or
versions of data in general (including slightly new but previously
unsupported/unhandled variations within the existing schema), then one
could envision a rollback.

--
Jess Holle

[jessh]

On 1/8/2014 1:35 PM, David DeMay wrote:
> Jess,
>
> Fairly frustrated right now that many fixes are marked ready for 10.1
> M050, but you can't get them without opening a xall for each and
> requesting a patch.
Understood.

To be honest, I'm fairly frustrated that I've fixed countless things in
10.1 M050 (and continue to do so), but it's not releasing until August.
Thus I have to re-diagnose known issues even when customers are on the
latest MOR and then help create patches for issues I've already fixed.
> There are some memory leak ones that should ve put into a generic
> downloadable patch.
There's probably lots of cases for a CPS-like delivery mechanism in
X-22, but this is new to X-24.
> As PTC handles supporting X-2x series of Windchill, new performance
> bugs should not be introduced in later MOR's because of X-24/X-26
> development in same module areas of functionality.
More generally we should be taking every reasonable possible against
performance regressions in all our MORs -- irrespective of the type or
motivation of software change that might be producing these regressions.

Generally speaking, X-26 changes wouldn't be backed into an X-24 MOR
unless there was a specific /need /for those changes in that X-24 MOR.
> We jumped from M010 to M040 and have had more issues, but stuck
> without a new MOR. We can not use 10.2.
Out of curiousity, why can't you use 10.2?
> Perhaps you can forward this concern to who manages these decisions?
I'll pass this along to some folk who can hopefully carry this to the
right ears.

I certainly understand that leaving long periods of time between MORs
can cause big issues for customers unless the previous MOR was truly
really, really stable and had very, very few issues. I really hope that
the CPS model in X-24 helps address this.

--
Jess Holle

[ddemay]

Yes and the rollback should do a scan and account for this as part of the rollback. Should be easy to do. The mere mention of serialization scares most but the techies know a rollback mechanism is still feasible.


Sent from my Verizon Wireless 4G LTE Smartphone

[jessh]

"Account for this"?

How?

If you have new versions of data (and possibly new types of data)
squirreled away into BLOBs in the database, etc, I'm not sure how you
reasonably find it all -- much less fix it.

Or if you have subtle new arrangements of relational data one didn't
have before, I'm not sure how you'd possibly find such conditions.

[sdrzewiczewski]

Should these types of changes occur during a MOR?

[jessh]

Sometimes they have to.

That said:

1. I concur with the desire for a rollback feature.
2. I believe work could potentially be done to identify whether a given
MOR could possibly have this issue (through various source code
change analyses, etc) -- double-check the necessity of the change
and denote this as part of the MOR.

Without a rollback feature, one could try what I'd consider "best
cluster deployment practice", which is to manage one's installation
directory with a source control system. [I consider this "best
practice" for clusters because one gets full reproducibility /and/
traceability of the installation.] In this case one could revert the
whole installation directory to the previous version. I'm not sure
whether this would run into issues or not if one attempts to use this
for an MOR rollback.

[ScottPearson]

What's been interesting to note about the direction this thread has taken is that it drives home my original point of...., Installing the latest and greatest build of any software -- Windchilll, Creo, etc. -- requires a great deal of forethought, planning, implementation, and -- as always -- a Plan B in case an unanticipated problem creeps into the mix.

All that effort costs time and money...., and frequently it is not to "gain new functionality" but merely to "retain existing functionality" and "stay up-to-date".

And yet there was a criticism of why some folks choose not to install every build that comes along.

I'm a big fan of staying up to date for all the good reasons mentioned but when folks choose to stay put on a certain mix of versions of Creo + Windchill + you-name-it that is actually working for them, those users should not be criticized as if they were slackers. That criticism does not properly look at The Big Picture.

My two cents' worth...

Scott Pearson
Senior Designer
CAD System Administrator

[cid:image004.png@01CF0D16.CDDB59E0]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®
Space Science and Engineering Division
Space Systems Directorate
Department of Space Engineering
6220 Culebra Road, San Antonio, TX 78238