Hi guys, I have done something wrong while I was updating my dynamo and package and everything in between I had uninstalled and deleted everything dynamo related to revert back to dynamo 2.0even though I had 2.0.2 before I decided to go back due to some issues with the Orchid package and graphs I had which can only work in 2.0 version I need someone to guide me in the right direction please

Reinstalling Dynamo 2.0 or any other version of dynamo (2.0.1 and 2.0.2) will NOT solve the issue you have with mine or other packages there needs migration. Migration do not work at the moment internally in the entire 2.0.x series.

Those 20+ nodes I have moved around before I knew that migration doesn’t work are not going to work no matter which version you have installed.

I simply cant move them back again, since that would harm other users of my package…

I am left in a position where I can only wait for a new Dynamo 2.0.x version to be released as anybody else has to. You must replace “missing” nodes with “new” nodes, there is no way around this.

Please move the new issue to a new topic, and write up what the solution was (contacting @Kulkul for a team viewer session, while awesome, doesn’t work for everyone as there are too many forum users and only on @Kulkul).

@erfajo is it possible to install a version from before the 20+ nodes were altered via your GitHub repo? Similar to installing an older version on package manager? Could a ‘standard’ user see which 20 they should withhold and remove them from the package manually?

The problem is that I don’t remember when I eventually moved things around. Migration has always been a solid solution, so I didn’t expect this issue at all… I did test it between the 1.3.x and the 2.0.x version, always did it go well. At some point did I decided that the time was up for a split between the merged installer that had both the 1.3.x and the 2.0.x packages inside. At that point did I clean up history.

It is possible to get the old code back and make older version of Orchid since I can run rollback… but, it is to much work for me to do when it rather easily can be solved manually by changing nodes or use a notepad and do text replace.
What needs to be replaced can be found in my migration.xml.

I have tried to address this issue to the dynamoteam that this could become an issue for many users. I do also think that this should have been posted as a warning in the forum from the team. Such a critical error should not be silent.

I believe the GitHub site has an issue around the 2.0.x upgrade bug which has been open for longer than this conversation, and that there is a planned fix as well (@erfajo and others have linked to this previously). The input that there should be a transparent means of explaining these types of issues is quite useful - expecting all package managers to keep up to date with a bug list that’s in another platform is a bit much, and the forum isn’t as well traversed/organized for things at that detail level. Perhaps an inproduct view that opens a list of known bugs/defects when publishing to the package manager?

Well, it is on a recurring level that errors pop up, so the team is also excused for not knowing all that can occur, nobody is oracles.

In writing has dictionaries also some problems there is critical!

My suggestion is that those very critical errors are pinned in forum as important messages, or as you say @JacobSmall, make a special feed for critical errors there is easy and oneway communicated/maintained so the overview is clear to both users and authors of packages!

I will not say that Github issues are an answer, there are too much blurry information and issues floating around there. Meaning this is not fast and oneway communicated. Preferable is also that it is communicated somehow through forum!

I know that @john_pierson and @Michael_Kirschner2 are involved in communicating the issues at GitHub as well as here in the forum. They would be some of those I would trust as admins for such a service.

As an outcome of this issue have I renamed my executable installers, so they are named:
OrchidForDynamo_130.exe
OrchidForDynamo_200.exe

Previously did I include the major and minor number in the filename, but that meant that for every major/minor change came a new file name. Therefore, did I not have a history to roll back available at Github. This change should over time mean that historic executable should be available to get.

Here is proof of concept for building an internal migration for Dynamo 2.0.x versions.

This solution should be able to migrate all nodes in the Orchid package internally between Dynamo 2.0.x versions. The solution is based on the current package (202.3.11.6983) and the migration xml files come from that version. The nodes in the excel file are also from this version. The solution uses also JsonDate nodes by @alvpickmans