If you are moving between 2019r2 and 2019r1.1 on the same project be aware that you can lose work done in 2019r2.
If you plan on keeping a project usable by 2019r1.1 users and work on it in 2019r2 you might be a bit surprised when the 2019r1.1 users report lost data from your projects.
Having specific icons for 12r1 and 12r2 start to be mandatory (MBS implementation idea was the best IMHO).
Check our QuickLook Plugin for Xojo Projects here:
https://www.mbsplugins.de/archive/2016-02-29/Check_our_QuickLook_Plugin_for
I also recommend duplicating all shared external classes on disk then replacing them to protect your project’s r1.1 version.
Note that when doing this it’s important to drag your r2 classes into the project BEFORE deleting the r1.1 version, otherwise all your control classes will lose the reference to the external class.
Oh well… Exactly what you’re showing in your ScreenRecording has been reported early enough in the Betas…: <https://xojo.com/issue/57016>
And guess what… this is considered “not a bug” (and I think to remember in one Forum answer even kind of “by design”) 
Everything you add to your layouts in 2019r2 will only get the “new/renamed properties”. So it won’t be backwards compatible.
Every previously existing Control gets the “renamed properties” doubled-up. They’ll be “synced” in 2019r2 (to remain backwards compatible). But not any newly added stuff in 2019r2.
Which boils down to: Always code and save in the oldest IDE you’re going to (have to) use…
And btw: I haven’t found a way to get clean project files with existing code/layouts (even if you’re intending to go “2019r2+” only) - meaning to get rid of all those “doubled properties”.
From my point of view, this is just a mess… both “backwards compatibility”, and “migrate existing code to 2019r2+” (doing a “save as”). Until that’s going to be improved/fixed, we’ll continue saving in pre 2019r2, and in the best case just use 2019r2 as a “build only” version.
I thought they spent considerable time after that ticket was closed to make 2019r2 retain backwards compatibility for 2019r1.1 projects which included things like adding events with r1.1 names and properties with both new and old names so they could be opened in both versions.
I could be mistaken though as the beta was exceeding lone but I thought this was one of they areas they spent a lot of time re-engineering to get it right.
Yup… but only for “existing code/Controls (saved in pre 2019r2)”. Not for anything newly added/created in 2019r2. 
Even though the 2019r2 IDE knows that it’s a “pre 2019r2 project”, it doesn’t save any “old properties” for newly added Controls so that it would work in pre 2019r2.
I did not think that it would do that with a pre 2019R2 project.
Well that means R2 with definitely be at best compile only for me
it does
its painful
one reason I gave up trying client code
This implies that if you don’t use “Save As” (which incidentally I didn’t use in that ticket) then you can go back and use a previous edition on that file. This clearly isn’t the case as is demonstrated in <https://xojo.com/issue/57853> which has been closed as “By Design”?
I’m confused, could we get some clarity on the state of backwards compatibility because there seems to be conflicting messages coming from Xojo?
@Greg O’Lone or @Geoff Perlman Any comment on this guys? Should we be able to use 2019r1.1 projects in 2019r2 without fear of losing data or is this a bug? <https://xojo.com/issue/57853>
I’ve reopened the case, however it should be noted that this problem only affects Binary projects. XML and Text projects seem to be working fine.
Thanks Greg!
No. It happens to .xojo_project’s too.
All the time during Betas (when we’ve reported that already). And of course now with the public 2019r2.
This thing of multiple save/load formats, and 3 points of failure (bin, xml, text), causes troubles all the time. Again, for me, Xojo should go for a pure text only format ASAP, with packed and open options only (the “open” is just a folder tree of files and sub folders, the packed is a ZIP file with a copy of that SAME content followed by a “collect project items” integrating everything in something “transportable”).
“Oh! But saving text is the main difference of the public free Xojo and the paid one”. Nope. It’s building the app instead of debugging it.
There are significant numbers of the user base that ONLY use the binary format and that’s it. They like it because it’s a single file and they do their own version control. I can’t imagine doing that but it works for them. Hence the 3 formats.
FWIW, the binary and XML formats are very similar. It’s the text format that’s the odd man out. But since Xojo uses the text format for source code and version control it is (usually) pretty stable.
The “packed save” is one single file. Sure, slower to open (unpack to temp folder for edition), but stored as one file after edition, closing, or another “Save As…Packed”. Historically, I’ve seem examples of when saving XML, systems got broken, then, other times, the text got broken… Now, the binary is broken. You must fix the same thing in 3 places. This is not very smart. And we have just 2 necessities: Save as ONE portable pack, and save as open text for a VCS (like GIT) and sometimes a fast external edition (like an online edit). Old formats can use a Xojo conversion tool.