Well who knew???
Assigning the value %nextrevision% to a variable doesn't cause %nextrevision% to be calculated then stored in the variable. It merely reads whatever is in %nextrevision% and I don't know what told %nextrevision% to figure out what its value is.
You can assign %nextrevision% in as many actions as you wish in a single transition without causing a change in its value.
So to solve the problem I created for myself, I merely execute the action as many times as I need.
One day... nah, I will never figure out all the tricks, traps and truck-ups of variable assignment in EPDM!
Yeah, it is ridiculous we have to go to so much trouble to copy the EPDM Revision to a useful variable (which can be displayed in columns, can be searched, etc). I didn't understand your misconception until I read your second post. Revision Components are a static list (set up as you desire), and so %nextrevision% simply gets the next one, and as you said, that value will remain the same until an Increment Revision action is run.
I create the copy (called RevPerPDM) in the same Transition, just before I increment the EPDM value. Are you writing your variable in a different transition than the one that increments the EPDM Revision? What kind of tricks are you doing?
This post shows an image of how I set it up. Re: Using Numeric and Alpha Revs in a single workflow
My variable called "Revision" can change separately from the EPDM revision.
Also I have a numeric (prototype release) and an alpha revision (fully released), which one is current depends on the workflow (they are not major and minor, it is one type or the other at a given time), but I only increment the RevPerPDM when the EPDM alpha revision is set. So it keeps track of full releases (without needing to look through the history).
Brian -- fun read! The weirdnesses certainly are entertaining.
Sounds like we are doing the same thing -- I set a variable to track the EPDM revision in exactly the same way you do, that is right before the EPDM revision is set.
I use the major/minor revision in the same way you are using your alpha/numeric combination. The outside world should only ever see whole number major revisions MM and our internal world will see major.minor MM.mm (or just .mm early in the process).
There is probably little difference in what any of us do in terms of tracking revisions.
- I have a FILE revision, which is a custom var, which is incremented at the START of a change process.
- The actual EPDM revision value, which is written at the END of any change process.
- Then there is the trackEPDM revision custom var, which holds the same value as the EPDM revision, written immediately before the EPDM revision is written, which allows me to track the EPDM revision of a file and use it elsewhere.
So a file could have a FILErev of 1.06 and an EPDMrev of 1, which would tell an observer that there is a released in the wild file out there at rev 1, while a change process is under way internally that is obviously under heavy debate. When the changed file is released. it will get FILErev 2 and EPDMrev 2. Seeing identical values means all is well with the world. the trackEPDM custom var just makes that file's EPDMrev readable elsewhere.