Hello
#DynamoBIM Package authors! We need your help.
Hot off the press is our brand-new Package Manager Website which has been given a fresh coat of paint and some fun new tools to play with. This sits alongside the updated features inside Dynamo Core 3.4. Read on to learn more!
Why:
For Dynamo users, there was no easy way to find the right version of the package that will work for their respective Dynamo setup. For Package Authors, it was a struggle to inform users of the correct package version to use and often had to wait until the next published version to update description and details.
What’s New:
- The Package Manager in the recent Dynamo Core 3.4 release, has a bunch of new features including a new install button that defaults to a package version compatible with your Dynamo setup and compatibility information to help users find the right version.
- The revamped Package Manager website , will be an essential resource for all Dynamo users, providing another way to access the vast array of packages that enhance and extend the capabilities of Dynamo.
- For Package Authors
: A new workflow to enable authors to log in and update/add package details and compatibility information to existing package versions.
- For Package Consumer
: To extend the benefits to users of older versions of Dynamo, we have brought the new package compatibility feature to the Package Manager website.
Call to Action: This new Package management experience will only get better with time, and we can do that even faster with help from all of you! If you are a Package Author, please log into the Package manager website and update your package compatibility information. Check out our a deep-dive blog post for more details on the new Dynamo Package Management experience: Discover the New Dynamo Package Management Experience - Dynamo BIM
Thank you for your support and helping both the community and Dynamo grow stronger together! 
11 Likes
This is great!
@achintya_bhat quick question: Is there any possibility of programmatically deploying the library to https://www.dynamopackages.com/ in the future?
For example, having an endpoint that could be used to push the package via the CI/CD pipeline could be very handy.
That will open the possibility of deploying the package using GitHub actions, NUKE or Azure Pipeline.
Thanks.
@sonomirco At this time, we are not exploring this option for external users. But, having said that, we do understand the convenience and efficiency this could bring to our advanced users. So, in the future we will evaluate the need again and keep this in mind for future improvements to publish workflow.
2 Likes
It would be nice if it was allowed to set only one valid version:
Due to some API breaks in Civil 3D, a certain version of my package is only working in Civil 3D 2025.1. But I can’t set that in the Package Manager…
Personally I would like to be able to set a minimum version, and leave the maximum version blank (which is also not possible).
Instant edit: It is also not possible to enter Civil 3D 2025.2 
1 Like
@Anton_Huizinga Thanks for reaching out. We do not allow leaving the max filed blank as it always expects a range. We have the “Add individual versions” option for packages that are compatible with one or more versions that are not necessarily in a range.
In your case, if you just want to add individual versions, then you can use the “Add individual versions” option as shown in the image below.
If you know that your package is compatible with all Civil 3D versions <2025.1, you can choose the 2025.1 - 2025.x as your range as shown in the image below.
But, you are also right that the Civil 3D version list is currently missing some minor/patch versions. We are working on updating this list.
1 Like
@Anton_Huizinga We have an update from our end. You can find all versions of Civil 3D and Revit in the drop down list.
Please let us know if you still have any issues with updating the compatibility information for your package. The team is working on making further improvements, so any feedback on this new workflow is much appreciated.
2 Likes
Thanks! I still would like to see that you can select the same version for from and to. I have one build that only works in Civil 3D 2025.1, so from and to is just valid for that version if I could set this. It feels like a workaround to leave them empty and add this specific version as extra.
My latest version is valid from 2025.2 to 2025.x. Litterally it could mean that 2025.0 and 2025.1 is now also seen as valid Civil 3D version because of the x. It would be great if the from and to fields are optional in any case. Now I have to enter a to-version but I am not sure if a potential 2025.3 will work, or the 2026.
(It would be the best situation if there were no API breaks in minor Civil 3D versions.)
It feels a bit of a hassle now, and at some point I think, it is easier to not going to bother with this all. Which is a pity of all the effort you put into it 
@Anton_Huizinga Thank you for sharing your honest feedback with us.
Given the wide range of packages and multiple combination of compatible versions and host programs that we support, it was a complex matrix problem for the team, and we wanted to keep it as simple as we can while meeting the wide range of combinations. To be honest, internally we went around on this longer than we’d care to admit. Finally, we decided on:
-
Range as an Input: Specify the minimum and maximum versions of Host/Dynamo your package is compatible with. For example, 2025-2025.3 means compatibility with all versions of Civil 3D between 2025.0.0 and 2025.3.
-
Wildcards for Maximum Range: To reduce upkeep, you can use wildcards (e.g., 2025.x) to indicate compatibility with future minor and patch releases. If your package works in C3D 2025.2, you can set the range to 2025.2 – 2025.x, covering all future 2025 versions.
-
Individual Versions: You can add specific versions if unsure about future compatibility. For instance, add version 2025.2 if you’re not sure about 2025.3 and beyond. Multiple versions can be added this way.
A big reason for us for not allowing the max field to be empty was that we did not want to leave any room for assumptions here. For example, if an author picks only “From” as 2025.2 and leaves the “To” field as blank, it could mean two things:
1. This package is only compatible with 2025.2
2. Or this package is compatible with all versions of above 2025.2
With the current format, it avoids ambiguity: use individual versions for the first case and wildcards for the second.
We recognize the confusion with “(all versions)” in 2025.x (all versions). This was an oversight, and we’ll fix it on the website. This 
is how it is intended to appear for users as you will be able to see in package manager in Dynamo Core 3.4.
We know this is not straight forward and nor is it the perfect solution. But, given the real case scenarios and the varied range of packages and hosts Dynamo supports, this was the happy path that the team picked. 
2 Likes
Thanks for the detailed response I do understand how things are decided and how they work from a programmer’s view. And I am really happy how Autodesk put a lot of effort in Dynamo lately, not only by extending it with new functionality but also by hiring highly skilled people with hands-on experience.
From a user’s perspective, on the other hand, it is not that clear.
As a package creator, there might be reasons why I couldn’t update the valid versions in time. Actually, it forces me to actively maintain the administrative properties of my package versions, each time a new Civil 3D or Beta is published. But if I forget to do this, or have not found time, users might ignore the package now because of the warning. Not every user is a blunt daredevil, so at best they try an older version if they really want it, or don’t install the package anyway.
The last item in the list is the most user-friendly. They are warned that it might be incompatible but friendly enough to try it out.
So, even while I understand the importance of a properly described package, to tempt users to use the latest version of my package, it is more convenient to mention no versions at all.
Hope you see my point too 
1 Like
Thank you for your detailed feedback; I definitely see your point. 
We introduced the wildcard (e.g., 2025-2025.x or 2025-2026.x) to help reduce the upkeep for authors. However, I agree that this does not cover all edge cases, especially when there are API breaks, as you mentioned.
We’re always looking for ways to improve the experience for both package creators and users. Your feedback is invaluable in helping us identify areas where we can make adjustments to better serve the community. Thank you for sharing this with us, and we will explore ways to address the concerns you raised.
2 Likes
