We encounter the same issue, due mainly to carry-over data coming from Intralink 3.4. There was less restrictions for Latest Released state in ILINK 3.4 and some people used it like that :
A.0 In Work
A.1 In Work
B.1 In work
Meaning that once the design was 'ready to be released', the version number was raised. It could sound illogical, but there was no pb for ILINK 3.4, Latest Released was Latest Released.
PTC answered us that PDMLink was designed like that, but there we are facing a kind of regression, as PDMLink is not capable to handle properly Latest Released objects.
So it ends with users trying to Add to Workspace the Latest Released objects, and checking object by object if what they have is really the latest released ones. If they don't do so, the Cad Check tool prior to release will see the error.
Issue has decreased since we are in PDMLink for almost 2 years now, and lot of objects have been newly revised and released, but it didn't help users' confidence in the system.
At Weatherford we have a similar requirement and process. We use a workflow that runs when a new version is created, this calls an expression and helper class that sets the state on the previous version to “Superceded” (yes, we know it is spelled wrong), this also sets the state on any linked WT documents and EPM Documents to match the wtpart. So the old part versions and their linked documents all end up in the Superceded state.
Users outside of Engineering may be given “Read Released” permissions to view WT documents and EPM Documents in the Released and Prototype states. We also allow users with this permission to view wtparts in the Superceded state, this is so they can use the “compare” function in Windchill to review BOM changes between wtpart versions without being able to access the out of date linked documentation.
On a related note, and something to add to a wish list would be for Windchill to have a database stored “Latest version”, which works similarly to how the “Latest iteration” does today. This could then be used to support some specific access control rules around those values. In addition to access control this would also make running reports on “latest” much more efficient.
As an aside, I was once in a meeting about Reports during the Technical Committee meetings in 2010 where a PTC representative assured us that there was a “latest version” feature in the software. I challenged this statement at the time and was assured that I would be sent instructions/documentation for how to use it…….. (still waiting). The only way I know of to “reliably” get the latest version is to use a “max” function comparing versions in the report, which is a resource hog.