When to sacrifice backwards compatibility?

views:

answers:

When to sacrifice backwards compatibility?

Basically I am wondering about having this behavior in an app where the newer versions require the content created with the older version to be (automatically) converted to the newer version format, at the cost of backwards compatibility.

Visual Studio does this for its .sln files.

Are there any pros/cons to this practice?

I guess in the context of the app I am writing (3d content creation), I was thinking of finding potentially different ways to create things in time (faster, better, more efficient) which might only be possible to implement if the older content files are converted to the new way of creating the same thing in a seeming similar way.

So for instance, maybe v1 had a Shape class where in v2 you realized you could do this more generically and faster by using a PolySpline class. But in order to have the old Shapes to be PolySplines you would convert the old content files and everything would be compatibile with the new version.

Is this a reasonable idea?

+1 A:

Unless you have a huge installation base and draconian upgrade policies/costs (like Microsoft with it's Office), you should have no problems with users needing to open new version files on older version of software. In other words, people frequently upgrade, but rarely downgrade.

One thing you can foresee and consider now is to create (a) some free player to let users that have new format file and old version of software see this new file (and maybe decide to upgrade) and (b) converter module that will convert newer format to older possibly dropping some unsupported features/elements.

Eugene Mayevski 'EldoS Corp 2010-10-01 19:26:34

Thanks, those are good suggestions.

Joan Venge 2010-10-01 19:37:43

+1 A:

A factor I haven't seen mentioned is whether nearly everyone who shares data will likely be using the same version of the application. It can be very annoying, for example, if a something like a sheet-music editing program saves in a format that is unreadable by earlier versions, since people who wish to exchange sheet music may very well not be running the same version of software. On the other hand, if a database will only be accessed by users within a small shop, plan on just doing a simultaneous upgrade of everyone and be done with it.

supercat 2010-10-01 20:19:42

I think for small apps, there shouldn't be a need to constantly scramble the file format, if at all. But for very large apps, this becomes inevitable if you want it to always have the best functionality IMO.

Joan Venge 2010-10-01 20:26:37

I think the best approach is probably to design a data structure from the beginning which can tag items with information that the current rev doesn't understand, and allow for a file to contain multiple redundant pieces of information along with information about which was last edited. Importing a file into an old version, changing something, and saving it back may cause semantic changes to information not understood by the old version, but if the new version can notice inconsistencies in the redundant data, it could flag things that were suspicious.

supercat 2010-10-02 16:30:05

ansaurus

tags:

views:

answers:

When to sacrifice backwards compatibility?

related questions