Skip to main content
1-Visitor
April 4, 2017
Solved

dual revision scheme

  • April 4, 2017
  • 6 replies
  • 7658 views

What would be the best procedure for switching revisions schemes between a development phase and a production phase? Our development phase would be alpha characters and at production would switch to numeric.

Best answer by TomU

State based versioning.  This requires a change to the configuration of the Windchill server.  Start with the help documentation here:

http://support.ptc.com/cs/help/windchill_hc/wc110_hc/index.jspx?id=ObjRulesChp_VersionSchemeChg&action=show

6 replies

TomU23-Emerald IVAnswer
23-Emerald IV
April 4, 2017

State based versioning.  This requires a change to the configuration of the Windchill server.  Start with the help documentation here:

http://support.ptc.com/cs/help/windchill_hc/wc110_hc/index.jspx?id=ObjRulesChp_VersionSchemeChg&action=show

jhamilton1-VisitorAuthor
1-Visitor
April 4, 2017

What do you use to drive the state change?

23-Emerald IV
April 4, 2017

Take a look at this picture:

By the way, Mike Lockwood‌ was the one who helped us set this up originally.

18-Opal
April 4, 2017

Jeff, that's exactly what my company does too.   Tom Uminn has excellent advice,  that would be a good place to start.

23-Emerald III
April 4, 2017

We are set up to that today. Alpha are released to a Pre-Production state and numeric revisions are Released state. All controlled by Windchill and the promotion process and Revise.

22-Sapphire I
April 4, 2017

I have thought long and hard about this - and have presented on it several times at PTC functions.  Attached PDF gives some info which may be useful.

Tremendous confusion (in my humble opinion) results from presenting "Promote" and "Revise" transitions on a single line, rather than presenting Promotion as clearly just changing the state of a given object and Revise being a "save as at the next Rev and start working on it."  With state-based versioning this becomes infinitely more important because some Revise transitions continue Numbered Rev's and others start or continue lettered Rev's.

State-based versioning with a two-phase lifecycle is a really great feature of Windchill - and very helpful to almost every company.  It's just super difficult to dig out of the documentation and examples how it actually works and how to configure for it.  Then, the OTB LC template presents an almost unworkable downside - have to release your last development Rev (see attached).

1-Visitor
March 2, 2018

On the last page of the attached pdf, is there a way to go back to numbered revisions after you've gone thru the one-time process change to go to alpha revs? 

23-Emerald IV
March 2, 2018

Nope.  Reason being that there is really just one big list of revisions and it's not ever possible to go backwards.

 

1

2

3

...

99

100

A

B

C

D

...

X

Y

Z

AA

AB

AC

12-Amethyst
April 5, 2017

There seems to be a lot of love for state based version schemes out there with the community big hitters. This is interesting.

We don’t currently use them, but I’m guessing if we surveyed all our engineers and asked them cold, “would you like to have them?” I suspect we would get more yes than no. In pre Windchill days some parts of the business did use 2 schemes.

After giving this some thought we recognized that state based version schemes are in essence a semi-intelligent numbering system. Comparisons can be drawn to intelligent part/document numbers. In our case the additional information stored in the intelligent revision number can more easily be captured in the lifecycle state.

For us, not having them simplifies configuration and use of Windchill quite a bit. There are less buttons to click, and a less complicated process to follow in general.

The only problem we have so far encountered with not having state based versions is that many people simply don’t like “the idea” of the first production revision being something other than “1” or “A”.

What do others think? I would be interest to hear the business drivers and perceived pro/cons?

22-Sapphire I
April 5, 2017

About "smart" or "intelligent" numbering...

Agree that this appears to be the main reason to implement - and in fact I believe it is somewhat helpful.

But the main reason to use it is that different states and state transitions along with different user permissions are in effect for numbered Revisions vs. Letter Revisions.  This very elegantly allows for distinct different business processes for the same data as it matures from development to production (along with as complex a one-time process for production release as desired).

For development (which just happens to be identified by Numbered Rev's (OTB - some switch these, esp. in Europe), set things up for minimal oversight / approvals and allow Revise freely.

For production (which just happens to be identified by Lettered Rev's) set things up for use of formal change management, and Revise only with an approved ECR.

jhamilton1-VisitorAuthor
1-Visitor
April 5, 2017

Thanks for all the info. Personally, I think not having the character change simplifies things greatly and is just another version of smart part numbering, which was good in its day, but somewhat unnecessary today. Unfortunately, with the nature of the business I am currently connected to, I don't have that option. So it would have to be state driven.

All this is ok, except for the fact that Windchill is not the friendliest piece of software out there. It takes a lot of effort and code writing many times in order to accomplish something rather simple.

My previous experience was with Solidworks PDM Pro where it was very easy to accomplish something like this. In Windchill, not so much. In many cases I know what I want to do, but getting there takes an enormous amount of hurdles.