Skip to main content
21-Topaz I
January 8, 2014
Question

Maintenance release

  • 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

24 replies

STEVEG21-Topaz IAuthor
21-Topaz I
January 8, 2014
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
1-Visitor
January 8, 2014

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


1-Visitor
January 8, 2014

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.
1-Visitor
January 8, 2014
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
1-Visitor
January 8, 2014
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
1-Visitor
January 8, 2014

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

1-Visitor
January 8, 2014

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


12-Amethyst
January 8, 2014
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

12-Amethyst
January 8, 2014
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

1-Visitor
January 9, 2014
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