I've been thinking about Indigo versioning a lot recently. Basically there are three axes:

1. Versioning of protocol implementation: Say Indigo v1 implements WS-SomeProtocol v1, how do we go about that implementation so that when WS-SomeProtocol v2 comes out and we want to implement it in Indigo v2 we can do so without breaking anything. I believe we have a good answer for this.
2. Versioning of applications: How do app developers version their Indigo apps? This is essentially a set of guidance and some features to support that guidance. I believe we have a good answer for this as well.
3. Indigo side by side support: For various reasons, Indigo needs to support side by side execution. There are two main opinions on what the versioning isolation boundary ought to be:
   - One opinion is that the isolation boundary ought to be appdomain. This means you can have two appdomains in the same process and each appdomain running its own version of Indigo. The reasoning is that an Indigo application may want to use a 3rd party component that also uses Indigo. Because the app and the component are versioned independently, they may need different versions of Indigo. The app can load the component in a separate appdomain and use some form of x-appdomain communication mechanism to talk to the component.
  - A second opinion is that the isolation boundary ought to be process. This means you can have two processes on the same machine and each process running its own version of Indigo. All appdomains in a process use the same Indigo version. The reasoning is that today the CLR and the .NET Framework are both process-wide (one version per process) so if an application and a component are using different Indigo versions, they may (maybe even likely) be using different versions of the .NET Fx so they can't be loaded in the same process anyway. Also, from an app developer point of view, since I already have to think in terms of process-wide for the .NET Fx, why should I have to think in terms of appdomain-wide for Indigo? It's easier for me as an app developer to just think of one versioning isolation boundary which, today, is process.

What are your thoughts on #3? Have you versioned applications from .NET Fx 1.0 to 1.1? to 2.0? How did you do it/plan to do it?

How do folks deal with moving from one ASP.NET version to the next? Do you upgrade the entire machine or do you run multiple application pools each with its own ASP.NET version?

I'd love to get your thoughts on this. Please email yassers _at_ microsoft _dot_ you know what.