Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Release and data management troubles
Hello,
I understand a lot of this could be due to the Arena connection for releases, but a few things I am noticing when submitting large releases:
- The release window is difficult to manage when you have 20+ drawings. Options for collapsing or expanding all items would be helpful.
- As you type in revisions, rows will collapse as the info admonitions disappear. It makes it difficult to quickly populate a lot of revisions when the fields jump each time you make an input. It takes a long time for these releases to populate in general, and rows will continue to shift long after you begin typing data.
- Being able to set all items to the same revision would be helpful, or use some sort of checkbox to bulk edit lines.
- When rejecting a release, sometimes I am unable to clone it (clone is grayed out), and usually means it needs to be manually setup again.
- There is a long standing bug (open ticket) where revision descriptions get wiped out when rejecting a release. I've had some luck with restoring the rejected version first, but I've been making a version just before submit so I can easily go back to it. This has been a lot of wasted time and energy on this one over the last couple years.
- It would be preferred that when I reject an Arena release, I just go right back to the draft release state, instead of needing to "clone". Currently you have to re-link a change number and repopulate all revision as if it were a new release.
- GLTFs have issues at times importing into Arena. Usually a retry fixes these, but that requires manual intervention.
- Tying releases to documents becomes a pain point when items are spread out over multiple documents on a single change. There is no way for someone else to know where a release is located. Likewise, it's unclear if a release is referencing a specific version of a part in another document or the latest version. If I make a change to a part that is on a draft release and then make a version, is the release referring to this one or the version it was when originally added? The bug from #5 seems to only apply to the document in which the release was created, with external items seemingly not impacted.
- There isn't really a great way to review all open releases or drafts across the product. I wonder if there is an opportunity to move releases to their own dashboard. Right now releases feel too buried and as a results releases will sit unmerged after approval until the next user sees a triangle symbol in a branch and knows that they need to go digging to see what needs merging.
- In general, merging still feels like a black box especially with drawings. When merging releases spread across multiple documents (especially where there are other open branches) I don't exactly have the confidence that I am not just overwriting a production drawing on Main with a previous version on an older branch that just happened to see a drawing update with a recent timestamp because of a minor metadata change.
These issues might not be universal, and there might be some things I can do to adapt, but releases on the whole are not something I enjoy doing these days. I know it will get better though!
Edit:
11. Along with #6, it becomes a tedious task to make a minor edit to a release sent to Arena, because you need to rebuild the whole release. It makes incorporating feedback a larger effort, and at times forces us to just submit things as-is on deadlines because it's too much of a head ache to fix. QA prefers reviewing in Arena understandably, since this is the actual source of truth. For example, BOM syncs might be done manually if it it wasn't synced prior, because syncing is locked when pending.
12. The revision in the revision table is not reliably updated when the drawing is added to a release. If a part is going from rev 3 to rev A, the table will show rev 4 until you submit the release and view it after the fact. When reviewing drawings with mfg and QA before an Arena submit, this is one of the most common bits of feedback, but I just tell them it will be correct when submitted.