Understood, hence the "not trivial" aspect of the issue. The big time that we would use it is as we are transitioning to a new version. We test it as thoroughly as possible and keep an eye out on the list for other people running into problems, but once we switch there is obviously no going back. Thankfully we avoided the shader fiasco of 2011 and jumped from 2010sp1 directly to 2012, hopefully our luck holds out :) -=T=-
On Wed, Apr 18, 2012 at 4:23 AM, Brent McPherson < brent.mcpher...@autodesk.com> wrote: > Ok, I was mainly talking about forward compatibility but even writing a > previous version of a file format out requires: > > 1) you know automatically what is changing between versions > > 2) you know how to identify and gracefully omit objects, operators, > connections and data that will not be recognized in the older format > > As stated before the persistence code in XSI is not centralized and > therefore it is still a significant effort IMO to do 1) and 2) above so I > guess we differ on the definition of "much simpler". ;-) > > There are also cases where we rewire/reorder graph connections or > version/replace operators to fix issues so we would also potentially need > to rewire things or write out different/older versions of operators when > saving the old format. > > In my opinion the save-previous-version strategy only works well for > standard file formats which are precisely defined and change infrequently. > (internal file formats do not usually meet this requirement) > > The simplest thing I can think of is to have a way to override the safe > behaviour and let the user import the file at their own risk. (equivalent > to changing the version number manually in a Maya ascii file) > -- > Brent > > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau > Sent: 18 April 2012 01:15 > To: softimage@listproc.autodesk.com > Subject: Re: 2013 save scene = no load in 2012? > > > What we said was that allowing the software to load a scene from a future > version is very difficult. Adding feature that allows the software to save > a file compatible with one version back is a much simpler problem. Much > less to test, and no time machine required. > On Apr 17, 2012 5:01 PM, "Eric Turman" <i.anima...@gmail.com<mailto: > i.anima...@gmail.com>> wrote: > But I was originally suggesting the prior...the one that Luc-Eric said > that "the team could conceivably consider." > On Tue, Apr 17, 2012 at 6:56 PM, Steven Caron <car...@gmail.com<mailto: > car...@gmail.com>> wrote: > nope, mixed up again... 2013 could in theory save a file knowing which > features 2012 doesn't support, but 2012 would need to radically change how > it loaded data from future (forward) versions and features it does not yet > know about. brent was talking about the latter. > > On Tue, Apr 17, 2012 at 4:52 PM, Eric Turman <i.anima...@gmail.com<mailto: > i.anima...@gmail.com>> wrote: > Wait...I thought that Brent said that it was not trivial to implement a > 'save as previous version'; It sounded like it would take considerable > resources to implement that. > > > > > -- > > > > > -=T=- > -- -=T=-
