Breaking the RDM / DPS lockstep requirements
Team, I completely understand the challenge of trying to get from where you were to where you want to be when it comes to authentication types, .NET Core, 32bit vs 64bit, etc. but as a customer, I am hoping we find a solution that doesn't involve a rapid deploy of RDM and DPS upgrades simultaneously. We run A/B deployment rings and will usually have about half on latest and half on n-1 versions. It also means I can lazily deploy patches to my rings and let them migrate over during their next log off/on. Most of the time, this works great but when we have a deployment like RDM/DVLS 2022.2.x.x where they both had to be updated at the exact same time, we had to collapse the rings and force log offs, etc. Not the end of the world, but I'd like to see more grace time in the products, where both RDM and DVLS can support current and at least one major version behind of each other.
Thanks,
Paul
All Comments (1)
Hello Paul,
The 2022.1 release completely changed the authentication model with the introduction of OAuth, so no backward compatibility was possible. In the future however, and it can be seen with the 2022.2 release, you can still use an older version of RDM to connect to your Devolutions Server data source.
Then engineering teams tries to maintain compatibility between the major releases, but it is not always simple, and it can, at times, not be possible. They do always keep it in mind, however.
One thing to keep in mind is that new features will not be accessible, so the functionality may be affected.
Best regards,
Richard Boisvert