I’d like to get others’ thoughts on best practices for maintaining package version compatibility with the latest stable Dynamo build.
At Woods Bagot I prefer to keep all users on the latest stable build to reduce risk on projects. Advanced users are welcome to push ahead to daily builds provided it doesn’t interfere with team collaboration.
The latest stable build, along with a recommended core set of packages, is deployed along with current versions of Revit. This means all Revit users, regardless of whether or not they actively use Dynamo, have the same Dynamo “ecosystem.”
Therefore it falls on me, each time a new stable is released, to go through each and every recommended package (16 at this point) and identify the most recent version built to the stable.
Many times this is one or two versions behind the most recent version of the package, as actively developed packages are built toward daily builds not stables.
This isn’t the most arduous task of all time but it feels a bit inefficient. I’m wondering if there’s a better way to manage this.
From a features request standpoint it would be nice to run an auto-update on all packages to either the most recent version or to the most recent version compatible with the currently installed Dynamo build.
Brian, This is something we’ve discussed frequently on the team. The pace of change leading up to Dynamo 1.0 is pretty frantic as we work to solidify APIs so that they do not need to change after 1.0. This leads to version incompatibility with many released packages. What we’ve discussed internally is an automated system that allows us to test packages, and inform the author when their package no longer works in the current version. This is similar to the automated testing we already run to ensure the stability of Dynamo. The trick is, that package authors would have to participate in this system by establishing a set of tests - most likely a set of workflows with expected outcomes that would live in their package and get run by this automated test system. We might produce some special tests nodes whose output must have a certain value in order for the test to pass. You’d wire these nodes into your test workflows, and the testing system would take care of downloading the package, running the workflows and checking the expected values. The results would include an email to the package author and a “badge” on the dynamo packages site indicating whether the package passed its tests on a specific version of dynamo. There is one other problem for you. You want to see your 16 packages without having to wade through a bunch of other package information. This makes me think that we should have some sort of “toolkit” functionality that allows you to mark packages as being part of your favorite set. This is one, of many, updates we should make to the packages site. i
