Comment by Nextgrid
1 day ago
Resetting the app ecosystem 3 fucking times by breaking app compatibility didn't help. Windows Phone 7 - Windows Phone 8 -> Windows (Phone?) 10.
1 day ago
Resetting the app ecosystem 3 fucking times by breaking app compatibility didn't help. Windows Phone 7 - Windows Phone 8 -> Windows (Phone?) 10.
Wrong. There was full app compat of WP7 apps in WP8 and Win10 Mobile, and for WP8 apps in W10M. The only full backward app compat break was from WM6.5/WP6.5 to WP7.
I'll give you the benefit of the doubt and assume you're thinking of the lack of device OS upgrades: from WP6.5 to WP7, from WP7 to WP8, and from older WP8 devices to W10M. So no forward compat, but absolutely yes to backward compat.
That's not what they mean. As a developer, the API you used to develop your app was now deprecated with no migration path. That meant your app was deprecated, with no migration path.
For an app platform already a distant third place and struggling to attract developers, pissing off the few devs you do have TWICE was not a smart move.
Even then, that happened at most twice as you say, not three times as the other poster said.
And I disagree with your implicit claim that the WP7 & WP8 Silverlight -> Win10 UWP transition had no migration path. There was >= 90% source code similarity, bolstered if you had already adopted the Win8.1/WP8.1 "universal" project templates. And Microsoft provided tooling to ease the transition. Sometimes it was literally just s/Microsoft.Phone/Windows.UI/g.
Games were a different matter, I'll admit. XNA as an app platform had no direct replacement that was binary compatible with Win10 desktop, but even then, not only was DirectX already available from WP8.0, but Microsoft invested in MonoGame as an XNA replacement precisely because they knew the end of XNA would hit hard. (In fact it was the Windows Phone division that had essentially kept XNA on life support in its final years so that WP7 games would not break.)
"the API you used to develop your app was now deprecated with no migration path."
Seems that's the standard now for .NET desktop dev. Every 2 or 3 years MS crank out a new XAML based framework that's not compatible with the previous and never gets completed before a new framework comes out.
i guess they needed to release all that pent up backwards incompatibility
You joke, but I honestly wonder if this period and projects didn't involve a bunch of Microsoft employees who got a little overexcited when they were told that they didn't need to maintain the insane, sometimes bug-for-bug, compatibility layers with 20-40 year old software that they had had to deal with their entire career there.
Must have felt incredibly liberating, and maybe they got a little too into the whole idea of "fresh start"(s).
See also Windows RT.