Hi I followed with interest the discussion but without many interventions. I want to explain an idea I have for supporting backward-compatibility without neither stabilizing the format nor getting the current code dirty. Maybe it's a bit crazy but I think it can be a practical solution. I would like to know your opinions.
We can offer: - Maintain a *compatibility package* for each released version, that can co-exist in the same image. For example Fuel1_5, Fuel1_6, etc. Obviously, the current version always has the nice clean name (Fuel). - Provide a facade that works like "Fuel load: aFile asOfVersion: '1.4'" who interacts with the compatibility packages. To generate each *compatibility package*, we rename several elements of the original Fuel released package, this way: * Extension methods: Append at beggining of each extension method selector a prefix. For example: #fuelAccept: --> #fuel1_6_fuelAccept: * Classes: Append to each one some version identifier. For example: FLSerializer --> FLSerializer_1_6 * Methods: Fix each reference to a class or extension method selector THAT BELONGS to the package. For example: "FLSerializer new" --> "FLSerializer_1_6 new". I think it could be not that hard to make such renames automatically with a small tool. Then, we can simultaneously maintain each *compatibility package* (Fuel1_5, Fuel1_6, etc.) when Pharo evolves: Our Jenkins will run tests for all the compatibility Fuel packages. For example... Does Fuel1_7 stop working in Pharo1.5? then (if it's possible) we fix it, save the monticello version and mark it in our ConfigurationOfFuel as "this is the stable monticello version of fuel 1.7 in pharo 1.5". Now that I see how many lines I took to explain it, I think it's a bit insane. I hope to read some opinions! Bests, Martín On Thu, Oct 20, 2011 at 6:00 PM, Schwab,Wilhelm K <[email protected]>wrote: > Mariano, > > I gave you a pretty tough time :) It appears that you understand that I > did so with the best of intentions. Thanks for listening. > > One problem that I do *not* think you need to solve is that of old software > talking to new software. Someone wanting forward compatibility is probably > going to use XML or something similar to get a timeless protocol that will > be of necessity very simple. A good serializer is hard to write, and > forward-compatibility is probably too much to ask, particularly when > efficiency is a stated goal. > > A backwardly-compatible Fuel will be most welcome and useful. > > Bill > > > ________________________________________ > From: [email protected] [ > [email protected]] On Behalf Of Mariano Martinez > Peck [[email protected]] > Sent: Thursday, October 20, 2011 7:00 AM > To: [email protected] > Subject: Re: [Pharo-project] When will Fuel file format stabilize? > > On Thu, Oct 20, 2011 at 12:54 PM, Ben Coman <[email protected]<mailto: > [email protected]>> wrote: > Mariano Martinez Peck wrote: > Well...thanks guys. The point is taken. Thanks Philip, Bill and all who > gave feedback and suggestions. We are aware of this and we are already > discussing with Martin possible solutions and analyzing all the things that > has been said in this thread. > We will keep you informed. > > Cheers > Just one thing I hadn't seen discussed. Is Fuel possibly a way to exchange > objects/data between users/systems ? > > Yes > > In which case it would have to deal with different systems having different > versions of Fuel. > > > Exactly. It doesn't matter whether the different versions of Fuel happens > in your own image or in different systems. So yes, it is the same problem. > Note this is not only a problem for Fuel, but for any serializer which does > not manages full backward compatibility between versions. > > > -- > Mariano > http://marianopeck.wordpress.com > > >
