RDM Versioning Pattern
I was wondering if someone could break down RDM's versioning pattern? Back when we first started using RDM (probably like 4 years ago), I had originally thought that the first two number sets indicated Year and Month (YYYY-MM), but obviously that is not the case with the latest versions (2022.3.35.0), and honestly maybe that wasn't the case either when we first installed RDM all those years ago (hard to remember).
Additionally, what is the relation of the versioning between RDM and the PowerShell module, where the current version is "2022.3.1.5". At first glance, this doesn't appear to pair very well with the latest RDM (2022.3.35.0), until you realize that they were both released on the same date. So it's confusing to me whether I should be using a lower version of the PowerShell module or not (maybe "2022.3.0.0"?). If the versioning matched, at least with the first three sets of numbers, then it would be more obvious, but as it stands I have to match up the release dates between the RDM release notes and the PowerShell module version history.
Not the end of the world, just a bit confusing for an end user (even a technical user in this case).
All Comments (6)
Hello,
The first set of digits is for the year (2022 for example). There are three major releases per year, those are indicated by the second set of digits (2022.3). For the last set of digits, it is for every minor version: https://devolutions.net/remote-desktop-manager/release-notes. There are more minor releases when a new version is released, for example with 2023.1 that will release in 2 weeks, and then it slows down, depending on if new bugs are found.
As for RDM PowerShell module, there is no link between the RDM, and it since they are released on different schedules. If the first two sets of digits match, they are compatible, but we recommend using the latest PS module since it includes bug fixes.
Best regards,
Richard Boisvert
Still a bit confusing for the consuming user, especially since we're well into the new year. But at least I know that I should only be looking at the two first set's of #'s now for pairing RDM w/ the PowerShell module.
Thanks for breaking it down!
Hello,
The new major release in the new year usually occurs at the end of Q1 since the last release of the previous year usually occur in Q4. Glad we could clear up the compatibility with the first 2 sets of digits.
Best regards,
Richard Boisvert
Hello,
If I may add, we don't change the database structure between the minor update and we make sure that our product suite is compatible together for each major update. In a nutshell, you should use RDM 2022.3 with DVLS 2022.3 but we do some minor adjustments/ bug fixes after the official releases.
Regards
David Hervieux
@David,
So just to clarify, DB structure changes could happen between, for example, 2022.2 and 2022.3, but not 2022.3.0 and 2022.3.X, correct? If so, then that is also helpful to know when considering team-wide upgrade strategies. For our team, I had previously decided to only patch every 6-12 months since I wasn't sure when the next "DB Upgrade Required" would be, therefore forcing an upgrade for all users (which can be pain to manage). So knowing that we can upgrade from minor version to minor version within a single major version w/o a DB structure change should allow us to update more frequently now, and on a per-user basis too (I believe).
It might be a good idea to add some sort of option in the RDM Version Management section to then specify to only allow upgrades until a DB Upgrade is required (i.e. within a single major version). I suppose, considering what you just shared with us, we could just set the min to, for example, "2022.3.0.0" and the maximum to "2022.3.99.99", which I would imagine would just be a catch all for every minor version within that major version, it's just not very clear that is how that works (until now).
Appreciate you chiming in.
Hello,
You can always refer to his KB for the database upgrades: https://kb.devolutions.net/rdm_version_compatibility_dps.html
Unless there is an issue that requires a database upgrade, it only occurs when a new major release is available. When you configure the automatic version management, it will set the version the minimum to xx.xx and the maximum to xx.xx.9999 - https://help.remotedesktopmanager.com/datasourcesettings_versionmanagement.html
For example, with 2023.1 (in beta currently):
Best regards,
Richard Boisvert