How to Add Description to Micro-Version?

matthew_stacy

Workspaces and Versions both have a description field within the  properties dialog box.

Is there similar functionality for micro-versions?

In my opinion it would be very useful to be able to add comments (comparable to description field in version properties) at any step in the design history without, creating a version.  Alternatively, a delete-able version would suffice.  Or a branch that could be deleted all the way back to it's root, regardless of prior versioning.  In short, I would like the flexibility to maintain a clean design history that provides enough information to be useful, without clutter.

In general I prefer to limit versions to a single primary workspace, typically "Main".  Otherwise their permanence can clutter the design history.  The best thing about versions is their permanence.  Paradoxically, the worst thing about versions is their permanence.  It is easy to produce a design history that looks like a spaghetti diagram.  I advocate using secondary workspaces to explore ideas that either:

1. Prove worthy of merging back into the primary workspace
2. Don't prove worthy of merging back into the primary workspace, but do earn a version (immortalized in the permanent archive) as a valid design alternative
3. The secondary workspace is deleted without versioning, because the design path didn't bear fruit

A comparable workflow in file-base CAD environments is to <ctrl><s> (save) whenever incremental progress is achieved and exit-without-saving-changes (or <ctrl><z> undo as far back as possible ...) when the model blows up or the design path proves unworthy.  OS branching and versioning is of course infinitely superior to  that.  But can we make it even better?

emagdalenaC2i

You can create a version and then add a description


I love using the Gitflow workflow in Onshape for product design (I do not recommend this method for project design):


Gitflow uses 2 timeless branches: Main (or Master) and Dev (or Develop)

1. You can create a new branch for each new feature or functionality you want to add (or explore) in the new version of your design.
2. Later You can merge these "Feature branches" in the "Dev branch"
3. Fix any issues after the merge directly in the "Dev branch"
4. Merge the "Dev branch" in the "Main branch"
5. And finally create a new version in the "Main branch", in this example 1.0

It also provides a slightly different method for "Hotfixes"

Lets suppose you are already selling and manufacturing your "amazing product" version 0.1
You define various functionalities that you want to add to the next version 1.0 that you want to develop

But in the middle of developing version 1.0, a customer calls about a major issue or a bug is discovered that needs to be fixed immediately, without waiting for version 1.0. In this case a hotfix is needed:

1. You create a branch from the latest existing version, in this example 0.1
2. Fix the issue in this new branch
3. Merge the "Hotfix branch" to the Main branch and also to the "Dev branch"
4. And finally create a new version in the "Main branch", in this example 0.2

This way you can provide version 0.2 directly to new customers, without waiting for the development of version 1.0 to finish.

matthew_stacy

@emagdalenaC2i, I greatly appreciate the detailed response.  You rightly point out that a branch can be versioned after the fact, at any location in the design history to add descriptive annotation.

But suppose that you were writing a book of poetry and you could never tear out or fully delete a page?  It's the hard-copy equivalent of a spaghetti diagram of branched workspaces in Onshape.  The description field in version properties is extremely useful, but sometimes fully deleting the branch simplifies and improves what is left behind.