Deciding when revisions should be incremented in a release cycle is a common debate that takes place when configuring workflows in SOLIDWORKS PDM. Should the revision be incremented before you start modifying the file to represent the new release, or after to represent the completion of your work and the transition to a released state? The answer: you can do it whichever way makes more sense to you, but there are some drawbacks to each approach that should be considered before making a final decision on which approach to implement.
What is a Pre-Release vs Post-Release Revision Scheme?
In a pre-release revision scheme, the revision is incremented before any changes are made. For example, suppose part1.SLDPRT is in the Released state of the workflow pictured below at revision “A”. The revision increments to “B” when it is sent to Under Revision Change to be modified. The revision then does not change when it is approved and sent back to Released.
This is the approach we recommend to our customers and is included in our best practices vault configuration. With this approach, the philosophy is that you’re modifying what will become the future revision. In order to represent the changes you will be making to the file, you increment the revision before making any modifications. Once all your changes have been made and the design is finalized, you release the file without changing the revision.
Pre-Release Revision Scheme
In a post-release revision scheme, the revision is incremented after all changes have been made and the file is ready to be released. For example, suppose part1.SLDPRT is in the Released state of the workflow pictured below at revision “A”. The revision does not change when it is sent to Under Revision Change to be modified. The revision then increments to “B” when it is approved and sent back to Released.
With this approach, the philosophy is that you’re modifying the old revision any time you’re making changes to a revision-controlled file. Once all your changes have been made and the design is finalized, you release the file at the next revision. That new revision stamps the final design and represents the first time the file is ready for production.
Post-Release Revision Scheme
Both revision scheme approaches have a single drawback that should be taken into consideration before deciding on which approach to implement. The one drawback of the pre-release revision scheme is the system revision found in the history won’t match the revision variable found on the data card while files are in the Under Revision Change and Change Pending Approval states. In the screenshots below, for example, the file started in Work in Progress and transitioned to Released at revision “A”. At this point, the revision on the data card matches the system revision in the file history. Next, the file transitioned to Under Revision Change at revision “B”. At this point, the data card displays revision “B” while the history of the file still displays revision “A”. Most users don’t find this to be an issue, but it can be confusing at first glance.
System revision matches revision on data card when in the Released state
System revision doesn’t match revision on data card when in the Under Revision Change state
The drawback of using the post-release revision scheme is that users won’t be able to see the next revision until the file is released. For companies that use a straightforward revision scheme (like a standard alphabetical or numerical scheme), this might not be a problem. For companies that use complex revision schemes built with many revision components, however, it can be useful to see the next revision before releasing a file. You can get around this issue by using the Set Revision tool to see the next revision in line, but some users may not have access to the Set Revision tool based on their folder and workflow permissions.
Using the Set Revision tool to see the next revision before releasing a file
We have seen customers be successful with both pre-release and post-release revision schemes, so you can choose to use whichever one makes more sense to you and your team. The key is to communicate clearly how your workflow is configured so there is no confusion about which method you are using or what the revisions on your files represent.
For information on how to configure revision schemes in your PDM workflow, see this blog article that walks through the procedure step-by-step: https://www.inflow-tech.com/blog/2017/07/solidworks-pdm-101-setting-document-revisions/
For information about the services offered at InFlow, visit https://www.inflow-tech.com/solutions/solidworks-pdm/services/