Backward-compatibility of Xojo project code

Xojo 2013r3.3 is the last version which supports Mac OS Snow Leopard. I have current licenses for Xojo for the next couple of years and intend to keep current, but I also need to continue building some apps for Snow Leopard …

The Xojo IDE is improving with each update, fixing bugs and so forth, so of course I prefer to work in the latest version of the IDE.

Is there any reason that working in the current IDE, saving the project, then loading it into the older IDE, should cause a problem? I know the answer to this might change with each new update to the IDE.

In the past there was a similar situation with the transition away from OS9, that I had to work across versions like this. So, I know the IDE may introduce new objects, etc. which will not be supported in the old IDE, and if I implement those as I work, the old IDE won’t know what to do, but I can avoid using the newly implemented items in my code since I will be only maintaining old projects when working this way.

Probably, I’m not the only person who finds himself in this situation. There may be other reasons to use older IDE versions as well. Therefore, I think it would be helpful if with each IDE release, there were a short note indicating the backward-compatibility of project code within the IDE history. Perhaps there is something like this already that I have missed?

Thanks!
Aaron

We make no guarantees about backwards compatibility.
Never have - it mostly just works but there are old IDE’s that have some issues / bugs that have been subsequently fixed.

IF all you do is open it and compile with the old version you should be fine.

If however you open, modify & save then you CAN run into issues with old IDE’s putting files in places you don’t expect OR with them
moving them around and NOT writing the VCP manifest correctly.

Testing the IDE for every possible item that might / might not work in a previous release would be an enormous task.
I doubt you’ll get a "list of “this works in the prior release this won’t etc”

At least as of now REAL/Xojo have worked this out very well, AFAIK you can easily load a new project into an older version of REAL/Xojo, sometimes as far back as RB2007, maybe even farther.

The point isn’t so much “will it work” (we can figure those things out often on our own) but whether it will simply load or not. I’d hate to see the day when Xojo 2015r3 produces XML files that cause REAL2011r3 to crash when it loads them. I would hope Xojo Corp. identifies the things that break the LOADING system of previous versions (that’s not hard at all) and is mindful of that.

I’m a expert at file formats and I’ve seen companies be mindful of this to their credit, but also ones that didn’t care and you can tell by their irresponsibility in how they map their files and how they identify them. One in particular used a binary format in v1, then shifted to XML in v2, but didn’t change their file extension and v1 bombs when trying to load v2 files - and the user has no idea wheat is v or v2 file - because of the extension. Booo.

Thanks, Norman - yes, of course, I wouldn’t expect that!

I meant something more along the lines Garth points out above. Some apps I own do change their file formats from one version to another, resulting in horrible situations, such as opening a file in the newer version, and then finding out that that file no longer even opens in the old version, even though nothing was done with the file in the new version - the very act of opening it with the new version breaks the file’s compatibility with the old version. This just happened to me with an app that was upgraded for Mavericks, and the company was also asking for a $35 fee for this backward-compatibility file-ruining “upgrade” (they didn’t get my money, and luckily I had backups of the ruined files).

So, maybe just a “heads up” if there is ever a change in the format itself that will prohibit working with old versions? I realize there is an easy way to answer this - just try to open it and see if it works, but I hope Xojo would include a simple note about this kind of change, should it ever be necessary.

And, I agree with Garth - it is pretty amazing how well you guys have maintained file-loading backward compatibility across IDE versions; kudos for that!

Thanks,
Aaron

[quote=73235:@Garth Hjelte]At least as of now REAL/Xojo have worked this out very well, AFAIK you can easily load a new project into an older version of REAL/Xojo, sometimes as far back as RB2007, maybe even farther.

The point isn’t so much “will it work” (we can figure those things out often on our own) but whether it will simply load or not. I’d hate to see the day when Xojo 2015r3 produces XML files that cause REAL2011r3 to crash when it loads them. I would hope Xojo Corp. identifies the things that break the LOADING system of previous versions (that’s not hard at all) and is mindful of that.
[/quote]
Problem is that what breaks an old versions is often something that we can’t change in the OLD IDE but that we need for new projects. Even if the new IDE writes it correctly & the old IDE may not load it correctly or skip unknown items correctly and then you have a problem.
This often happens with new segments added that the OLD IDE simple dies on.
We don’t go out of our way to write files that are deliberately incompatible - we don’t add new items that often - but I can say that it does happen

[quote=73237:@Aaron Hunt]Thanks, Norman - yes, of course, I wouldn’t expect that!

I meant something more along the lines Garth points out above. Some apps I own do change their file formats from one version to another, resulting in horrible situations, such as opening a file in the newer version, and then finding out that that file no longer even opens in the old version, even though nothing was done with the file in the new version - the very act of opening it with the new version breaks the file’s compatibility with the old version. This just happened to me with an app that was upgraded for Mavericks, and the company was also asking for a $35 fee for this backward-compatibility file-ruining “upgrade” (they didn’t get my money, and luckily I had backups of the ruined files).

So, maybe just a “heads up” if there is ever a change in the format itself that will prohibit working with old versions? I realize there is an easy way to answer this - just try to open it and see if it works, but I hope Xojo would include a simple note about this kind of change, should it ever be necessary.
[/quote]
Well there is always the “This was created in a newer version warning” - you can just close without altering the project
And project files do carry a version flag that says what we believe is the oldest version that can open the project - but if you get an old enough IDE they don’t know anything about that item & gleefully skip it

Great; that’s helpful … but looking at an XML project file for such a tag in the header block, I don’t see it. Is it only in binary files?

In XML its the second line right after the XML header

in VCP its pair like
MinIDEVersion=20070100

But that will sometimes vary by project type as well

So for web projects you might see

As we know that trying to open projects from version newer than 2011r4 in versions older than 2011r4 results in problems
They literally don’t read the project right

Thanks! - No idea how I missed that; I was staring right at it! ( slaps forehead ) The extra info is also helpful. Thanks again.