Soft Upgrade and Downgrade

[Rick Hillegas]

I'm looking for an explanation of how Soft Upgrade is supposed to work, 
from the customer's perspective and from the developer's perspective. I 
suppose that this also entails an explanation of the inverse operation, 
Soft Downgrade. I can't find this explanation.

My naive understanding of soft upgrade is that we do not want to require 
that server code and data be at the same rev level. Instead, data at a 
given rev level should be readable and writable by all subsequent revs 
of the server. But this a vague description. It is apparently ok for 
advanced features to not work against down-rev data. I can't figure out 
what limitations are considered acceptable and how those limitations 
should manifest themselves to customers. Are there general rules or is 
this decided on a release-by-release basis?

1) What is the customer-visible behavior of Soft Upgrade and Soft 
Downgrade?  The 10.1 Release Notes are silent on this topic. The 10.2 
Developer's Guide lists 10.2 features which won't work on softly 
upgraded data but is not explicit about what happens if you run a 10.0 
server against softly upgraded data. It just says that you can run a 
10.0 server against softly upgraded data.

2) Does Soft Upgrade in fact change the shape or content of any data in 
the database? If so, where do we collect the rules about what changes 
are allowed?

3) It appears that we expect to be able to run down-rev clients against 
up-rev servers running against down-rev data. For the most advanced 
server rev, the clients can range over all previous versions and so can 
the data. If there are N previous versions, Soft Upgrade creates N*N 
additional code paths which we have to test.

4) What is the customer problem solved by Soft Upgrade? Why can't we 
require that the server and its data be at the same rev level?

Thanks,
-Rick