best approach - version control custom component <=> definition file?

Dear reader,

What is the best approach to "freeze" a behavior of a definition file by ensuring that the version of the used custom components at that time remains the same? So even though the development of the custom component (/add-on) caries on and new versions will be installed, I want that specific definition (e.g. saved some were else) "ignore" the other versions. Preferably without too much user intervention.

Currently, we have the desired behavior with grasshopper clusters. When we internalize them in a definition the behavior is effectively frozen and will not be effected by other "installed" versions of the cluster. However, we are migrating to custom components and I don't think components can be internalized.

Regards, Wei Pien

Replies to This Discussion

Permalink Reply by Xavier AM on September 13, 2017 at 12:08am

Hello Wei, please have a look to this thread, it contains a lot of best practices on componenent version management :

http://www.grasshopper3d.com/forum/topics/io-generated-errors-which...

Permalink Reply by WP Lee on September 13, 2017 at 3:32am

Hi Xavier,

Tnx for the reply and insightful link.

These mechanisms can help. I'm a bit worrying about code maintenance since our components use common code and/or assemblies which can also change. Furthermore, we release quite often and there will build up quite some "legacy" code which normally is just the passed of version control like e.g. GIT.

It might be useful for us if one could do that on assembly "level" so that one could keep copied of older assemblies or pull it from an artifact repo if necessary.

Permalink Reply by Xavier AM on September 13, 2017 at 4:16am

I completely agree with you. Then what about placing kernel functions/methods in another DLL and use the gha only as pass-through to the kernel? Would that help the version control?

I'd be interested in whatever solution you find to this problem!

Permalink Reply by WP Lee on September 13, 2017 at 5:10am

In the proposed setup, not really because that way you only add an extra layer. The problem is like this:

componentA_old=> function_common1_old; specificA_stuff

componentB_old => function_common1_old; specificB_stuff

mod function_common1

componentA_old=> function_common1_new; specificA_stuff

componentB_old => function_common1_new; specificB_stuff

but this way all versions of function_common1 must exist on top of all versions of the components with the corresponding guids. So no matter how far one abstracts, it the problem remains in my opinion. Only difference is that an extra abstraction will be create for e.g. specificA_stuff, but every time a new version and associates component (with new guid) has still to be created. And therefore all older components still have to exist.

Permalink Reply by Petras Vestartas on September 13, 2017 at 2:57am

Do you mean you do not want to have that annoying windows pop-up that says that components where re-compiled/changed?

Permalink Reply by WP Lee on September 13, 2017 at 3:48am

Hi Pertras,

Think of it this way: we want to release (deploy) both new versions of the our add-on and related definitions as a template/examples. Both can change every release.

Given a certain version, a user starts with a template definition, and the user changes the parameters and such, there is a desire that the whole "instantiation" can be saved in that specific state and behaviour. This is because they just want to run it in the future with slight changes without figuring out whether the current newer version could reproduce the results that they had before.

Another scenario is when a user starts with a black definition and with a version of our add-on. What has been created should be coupled with that specific version of the add-on if the user decided the definition is a golden/final version of their creation.

RSS