However, I recall with the release of Roon 2.0, one of the stated capabilities was that Roon Remotes at differing versions would be able to access the Roon Core. It was stated that all of the functionality may not be available to the Roon Remote remaining on Roon 1.8 but the basic functionality would remain.
This gives Roon the ability to deprecate support for older OS versions and just focus on latest versions for Roon 2.0 development.
So as part of the Early Access program I would expect that EA builds of Roon Core works with 1.8 Legacy Production builds in addition the 2.0 EA builds for Roon Remote to confirm and maintain this capability.
This capability is not present with this latest Build.
I think your assumption is incorrect. The Early Access program was introduced for developing Roon 2.0 further, it was never intended to work with 1.8 Legacy - the latter is now frozen.
Not looking for the downgrade back from 2.0 to 1.8
Perfectly happy with Roon 2.0 on the Roon Core and with Roon Remote on my iPad Pro, iPhone (iOS 16) & even a iPad Mini 2 (2013 vintage and stuck on iOS 12), just have a legacy Windows machine for some tools and the WinXP emulation mode to be able to program Beo5/6 remotes. So it would be good to have the Roon Remote 1.8 Legacy version able to connect to Roon Core 2.0, as detailed in the Roon 2.0 Release Notes.
@simon_pepper, I remember it being something different. I believe Roon Labs has stated that the most recent version of Remote Remote Production will always work with the most recent version of Roon Core Earlyaccess. In this way it would not be absolutely necessary to use (the most recent version of) Roon Remote Earlysaccess; the latest version of Roon Remote Production can also be used (excluding of course the changes made in the latest version of Roon Remote Earlyaccess).
Do you have a link or quote of that? I canât find any such thing in the Roon 2.0 Release Notes, or Iâm missing it. Neither here in the actual release notes,
It is here in this statement - where different versions of Roon Remote and Roon Core can work together - hence a version of Roon Remote 1.8 Legacy is not forced to work with only a Roon 1.8 Core, but can work with a Roon Core at 2.0 also.
Yes, I understand that EarlyAccess versions of Roon 2.0 Core and Roon 2.0 Remote will only work together as this is during the development/QA phase, but here the version of Roon Remote 1.8 Legacy is now feature frozen.
Roon 1.8 Legacy has always required a corresponding Roon remote version.
âYou will need to install the Roon 1.8 legacy app on a Roon Remote/iOS device first before being able to take the downgrade. Itâs important to note that you will be logged out of your Roon account when you downgrade from Roon 2.0 to 1.8. This is because Roon 2.0 and Roon 1.8 use different account login mechanisms. You will be able to log back in afterwards.â
âWith the release of Roon 2.0 we will not be attempting to force a match between build numbers of Roon Core, Remote, Bridge, or ARCâ
I understand this is hard, backwards compatibility and ongoing support of older versions always is - thatâs why most development teams just want to support the latest version of an OS, Internet browser, Phone OS, JVM, compiler version, utility library, language version etc.
As a Software Product Manager for the 25+ years I have heard it all from the days of Windows 3.11 support, Netscape browser, Visual Basic, K&R C vs ANSI C etc.
You are confusing build number with version. There was never any intent to make the Roon remote backward capable with Roon 1.8 Legacy. Anyone who is on Roon 1.8 Legacy needs to use the Roon 1.8 Legacy remote version.
Roon 2.0 requires the corresponding version of Roon 2.0 remote.
Donât want a Roon 2.0 Remote to work with a Roon 1.8 Core.
Happy with Roon Core at 2.0, along with the majority of my Roon Remote applications running happly on iOS versions and a work laptop. Just one old Windows machine that is stuck on Roon Remote 1.8 Legacy, that up to this latest build was happy working with Roon Core 2.0
Granted Roon could have been more explicit but itâs always a tradeoff in order to not be overly verbose.
Unfortunately you are optimistically reading a little too much into that release statement ⌠which is about Roonâs deployment process and build numbering convention, rather than interoperability.
Pre Roon 2.0 the Roon build numbers were always âlock-steppedâ so that the current build numbers were aligned across the core, remotes, etc. ⌠pre 2.0 a new core build would also trigger a new remote app release even if there was no change to the Remote.
Going forwards this is no longer the case, which is why the latest build number for each component is now published separately.
There has never been a statement from Roon that Cores would be backward compatible with older versions remotes (or vis versa).
I hope I have clarified the situation, but will tag @mike at Roon as he may wish to review that original statement to avoid any ambiguity.
I always took âWith the release of Roon 2.0 we will not be attempting to force a matchâ as meaning between different builds within the 2.0 series. It doesnât say specifically, thatâs true, but neither does it explicitly say 1.8 and 2.0, and to me it seems that the difference is too large and will only grow. And I suppose there are separate 1.8 Legacy and 2.0 remote versions for a reason.
I think it was flipping clear that they were different, 1.8 wonât be supported for ever and 2.0 needs 2.0. anything else is logic chopping at its finest.