How should an application developer handle Adobe AIR upgrades on Windows and Mac?

Question

Hi,
My questions concern Windows 7 (and later) and Mac OS X:
Is Adobe AIR upgraded automatically? In other words, by default (if the user does not uncheck something during installation), is there a service/polling mechanism that checks for a new version of Adobe AIR and recommends an update to the user?
What happens if a user has an older version of Adobe AIR installed, and my application requires a more recent Adobe AIR version? Do I, as an application developer, have to do something or is it handled by Adobe AIR automatically?
Have Adobe AIR introduced many backward compatibility issues in the past? Is it possible for a user to have multiple versions of Adobe AIR installed at the same time? Can I, as an application developer, specify that this exact version of Adobe AIR is needed by my application?
If there sometimes are backwards compatibility issues with Adobe AIR. Is there a way for me as an application developer to try out a new version before it is released to the normal users? In other words, is there a way for me to make sure that my application works with the next version of Adobe AIR before it is released by the normal channels to the general user base?
Is there something else which should be taken into consideration when it comes to Adobe AIR upgrades and versioning issues?

Answer 1

Well we would suffer especially much from two of the drawbacks listed at Packaging a captive runtime bundle for desktop computers:
The AIR in-browser API for installing and launching an AIR application from a web page is not supported
AIR update API and framework are not supported
We are using the Air application as a solution for printing, which is invoked using the AIR in-browser API when the user clicks the "Print" button. I would guess the route to make it work with a captive runtime (which was something new to me), which I see as a normal stand alone application, would be to register a specific MIME type with the OS and each Web browser which is handled by our print application. And let a file of our new MIME type contain the information passed in the in-browser invocation at the moment. That would trigger the application when a user clicks Print.
We also use the AIR update API to update our application. Being without it means that we would need to create our own update mechanism.
These two paths to handle the given drawbacks above would mean a lot of work for us. Especially as we want to support both Windows and Mac. It might be worth it if the answers to my questions in the original post indicates that we can expect another type of problems instead.
I am still interested in answers to my original questions. But we will certainly take the captive runtime approach into consideration. As I didn't know about it, I really appreciate your answer!