Controlling the publication of Featurescripts

Jaydeep_Sarkar

Is there a way we can control the publication of featurescript ?
Currently we have a bunch of featurescript that we would like to call from a wrapper featurescript. Just like releasing updates in conventional programming, is there a way to release the wrapper featurescript, similar to Partstudio release.
Or is there a way we can publish a featurescript so that it doesnt ask for update beyond a certain version level.

For Example:
I have a through hole featurescript at version X. I want this feature to not modify (or ask for update) when I modify my hole definition in the future when all the holes become countersunk by default.
I still want my previous hole features to be unaffected by this change, but want the user to use the latest definition when creating new ones.

Another example can be the change in definition of standard units. One may want to use the latest values in the new designs but probably wont want an update notification for the features developed before the change.

Is there a way to accomplish this or the requirement is way to complicated to handle through featurescripts alone ?


Thanks in advance !!!

This requirement is similar to : https://forum.onshape.com/discussion/11474/use-release-management-to-issue-featurescripts-aka-custom-features

john_mcclary

You can only version a full document at a time.

so, with that. You can create a new document, with only a feature script (and some pdf's of the usage.. etc.)
then the only lines in your feature script is an import of another document, that holds the actual feature script.
then your code is just calling the function from the import..

does that make sense?

kind of like a dll...
and your versioned public document is just a call to a function in the dll

Jaydeep_Sarkar

john_mcclary said:

You can only version a full document at a time.

so, with that. You can create a new document, with only a feature script (and some pdf's of the usage.. etc.)
then the only lines in your feature script is an import of another document, that holds the actual feature script.
then your code is just calling the function from the import..

Hello John, by using the wrapper featurescript we are trying to achieve a similar workflow as outlined by you.
We have all the actual featurescript being called upon by import functionality and the wrapper would basically be like a factory script which will create required features.
My query was more inline with how we do a release of Part Studios, which then if instantiated anywhere else will not call for an update upon creating new versions after the release (a static part document).
Can we have a similar approach for the Featurescript as i could find no way of actually releasing a featurescript. This will help us in avoiding confusions like whether to update the features when we will have multiple documents having many many custom features related to the wrapper featurescript. 

john_mcclary said:

kind of like a dll...
and your versioned public document is just a call to a function in the dll

As you have given the inference of a dll, we generally release a dll at a particular state. Now upon newer release, it wont ask the previous components (features and operations) for an update mostly because its document independent which isnt the case in Onshape. 
If today i make a change in featurescript and version it it will ask for updates (which i know is totally dependent on the user to update). Is there a way atleast to warn the user as to when (or not) to update the feature ?

Do let me know if I am making any sense (even i am getting confused with the possibility of designers mistaking an update (or not) and then end up with a broke design ).

john_mcclary

You kind of making sense.

so, if you want the user to update, than create a new version in the wrapper document, that is the public release.
then all of your minor versions you are instancing behind the scenes during development are done in a separate development document.

when you are ready to push a release, then set a new version in your development document and then open your public release document and update the code and create a new version there as well...

does that make sense?

Today lets say both documents are :
Public Doc "Feature X" Version 1
Private Doc "Feature X Backend" Version 1.26

the Onshape community sees:
Feature X.featurescript:
export import "\Feature X Backend" version 1.10

You decide the backend is ready for release...
create a new version for the backend, lets say Version 2
open Feature X and update it's featurescript import to version 2, then make a new version of Feature X: version 2

Jaydeep_Sarkar

So in that case, anyone who had used the Public Doc "Feature X" Version 1 will now get a prompt to update to Version 2 when they open their Partstudio ... correct ?

Will it be a better way to create a new featurescript incase we want to release after some levels of versioning.
For example we can rename the previous Pub Doc as FeatX-Release 1.0.0 and then create a new feature script with other modifications that we dont want reflected in the part studio using FeatX-V1 and rename it to FeatX-Release 1.1.0. 
I hope by doing this we can stop spilling unnecessary upgrades not pertaining to a newly created feature to already created features (This was always a way). But this creates lot of unnecessary Featurescripts, was hoping if we could avoid that.

The process you mentioned before works well if we may want to have some upgraded changes to be applied to the previously created features. There can be certain instances where I dont want the user the update his/her custom features. 

In Onshape, since all the features are treated as first class citizens, implementing an operation based CAD approach will be a bit of work then.

john_mcclary

Well, I wouldn't rename the document..

Whenever you create a version, then any document that references that document will get notified.

so if you do all your work on the back end, whether it is hundreds of versions or whatever.
When you're ready to release it, just jump over to the front end and update the export import line in the feature script. then create a new version.. that will add the blue chain link icon for everyone and let them know it's time to update.

If everyone is pointing to the parent document, then it won't matter what you do with the children...

Jaydeep_Sarkar

john_mcclary said:

Well, I wouldn't rename the document..

Whenever you create a version, then any document that references that document will get notified.

so if you do all your work on the back end, whether it is hundreds of versions or whatever.
When you're ready to release it, just jump over to the front end and update the export import line in the feature script. then create a new version.. that will add the blue chain link icon for everyone and let them know it's time to update.

If everyone is pointing to the parent document, then it won't matter what you do with the children...

This is what we want to control. Selectively giving the option to update the feature, i.e. for some versions the user can update the feature. But after some time we have to settle that the feature that the script creates are not going to change as per the current methodologies. Down the line I think it will be a sane way to create a new FS with modified backend documents as per the latest methodologies which shouldnt modify the previously created Products. We might or might not want the user to update previously created features.

For example: A company just acquired a Laser cut machine which could be used for latest designs that needs to be manufactured. 
Now the Hole feature needs to be modified to work with a laser cutter, where it was initially a 5 Axis milling operation.
In this case it will be better to have a new FS rather than modifying the ones that has already been used to create the Lathe operation. For both the operations, the Hole feature is same but not the operation. So in this scenario if i give the user the option to update the features then it wont help my case.
It will mean the designers are now only going to create laser cut holes rather than the lathe ones. So having different FS should help ?
Its basically reusing the backend FS to be used to create a new feature. Similarly you can extrapolate the same thought to different release ideologies we generally follow in operation based designing (CATIA). 

Will it be an issue if i say that the 5 Axis Hole creation is handled in FS-Release1.0.0 and the laser cut Holes are handled in FS-Release1.1.0 ?
Please let me know if the current approach as mentioned by you can help me with this scenario. 

john_mcclary

You shouldn't replace or remove functionality between versions.

In a case like that, you could add an operation type menu item. That way they can still use the same feature, rather than having to go find your other feature and add it to their toolbar.. And how would they even know the other even exists unless you notify them..

you should keep the versions to a minimum. But make the version name include some description of what has been added. That way they can see if it is worth updating all of their active part studios or just leaving them out of date. 

there is an improvement request out there that gives them the option to lock in their version in the part studio, when they just don't want to keep updating the part studio, or they don't want to be annoyed by the update icon when they have finalized the parts.
https://forum.onshape.com/discussion/12757/pin-a-featurescript-version#latest

owen_sparks

Just out of interest who is the "user" here?  If the user is looking at a version of a document then you're already safe from unwanted update icons as the version is read only.  If it's a CAD designer then presumably they'll be have more scope on whether to update the feature or not as they'll be in the live main workspace.

Also don't forget you can write to the FS debug window, so you could write a bunch of information there to allow your user to make an informed decision as to update or not.

It's interesting that Onshape themselves face these questions every day.  For example our feature studios make a call at the top as to which version of "standard" to call.  Better still they have a mechanism to test whether a feature rebuilds exactly the same between updates and can "hold back" features to older revisions if the new functionality breaks old features.

Cheers,

Owen S.

john_mcclary

The user is the End-User, or cad designer

Trying to prevent a bunch of annoying blue chain links in everyone's documents when the update may not be required in older part studios.

Jaydeep_Sarkar

john_mcclary said:

You shouldn't replace or remove functionality between versions.

In a case like that, you could add an operation type menu item. That way they can still use the same feature, rather than having to go find your other feature and add it to their toolbar.. And how would they even know the other even exists unless you notify them..

you should keep the versions to a minimum. But make the version name include some description of what has been added. That way they can see if it is worth updating all of their active part studios or just leaving them out of date. 

there is an improvement request out there that gives them the option to lock in their version in the part studio, when they just don't want to keep updating the part studio, or they don't want to be annoyed by the update icon when they have finalized the parts.
https://forum.onshape.com/discussion/12757/pin-a-featurescript-version#latest

@john_mcclary :
This is an interesting proposal. Will check with my team if we could do away with this work flow. So basically we can give the option to the user to select between different approaches (Old Approach and New Approach sort of thing). I n the Old Approach we could freeze it upto a certain version and keep on updating the New Approach so that the user can have the flexibility to use both the approaches.

I agree to the fact that we should keep the versioning to the minimum. Provide all the details in a related document for the FS upgrade version.
Moving up from traditional CAD development environment, this is one great approach that would allow us to come close to how we traditionally release binaries.