![]() A much better description of a software release cycle is that version x contains bugs (a, b, c, d, e, f), whereas version x+1 contains bugs (a, b, e, g, i). Ideally if there’s a bug in version x, then people will have the choice to revert to version x-1 if it interferes with their work, or upgrade to version x+1 which has a fix for this bug.īut of course that’s a woefully naive model. ![]() But also this installer would have to handle versions and uninstalling as well, which the Yak-server handles. On this issue it seems like there is no API available for stand alone executables to ask Rhino for information without being an installed plugin. Alternatively, I can make a simple install file, but I would prefer to be able to ask Rhino where the target folders are via a stand alone executable rather than make a robust install which searches through the windows registry and folders. My impression thus far is that it is difficult to see how product owners can manage their product thoroughly on the Yak-server, and that after the upload the product is somewhat out of their hands. Along with user friendliness, the plugin itself is made and funded by the software owners/developers themselves and I think they need a more sense of control over the distribution. ![]() The idea is to try to approximate a user friendly single installation, meaning that the interoperability with Rhino-Grasshopper(and other software) should not require any user action. ![]() It is my impression in this case that it is desirable to use a more conservative distribution, meaning that the plugin is to by default follow the main install of the software. ![]()
0 Comments
Leave a Reply. |