Thanks guys for all the answers and ideas. I really appreaciate all of them. And in fact, this thread would probably be a source of information for Fuel's future work.
But so far, nobody (janko?) yet answer my initial question of this thread. So I will copy paste it here and I will be willing to hear the answers:

"We cannot. Let me just give you my thoughts:

- It is a pity that we cannot make progress just because we break the format. If improving means breaking the format, we will do it.
- The main question is WHY you need to update Fuel all the time? which are the reasons behind that?� I have only 3 things in mind:
a) because Fuel is too slow for you and hence you need a newer/faster version
b) because you have changed Pharo version and Fuel doesn't work anymore there with the same version?
c) because you found a bug.

a) looks unlikely. I think Fuel was fast enough for most scenarios from the beginning even if new versions are faster.
b) is unlikely also. For example, the last version (1.6) works out of the box in Pharo 1.2, 1.3 and 1.4. So it means that even between 3 versions of Pharo you don't need to update Fuel.
c) we haven't found so far a critical bug which would requires to update Fuel.


So...my question is, WHY you need to always use a new version of Fuel and why you cannot stay with a stable/fixed Metacello version? That's why we have metecello configurations. You can stick with version 1.6 (or whatever version) and just migrate when it is really necessary.
For example, Francois Stephany is using Fuel for his website, and he is still using Fuel 1.4. He didn't need to update yet, because there aren't bugs and it is fast enough for what he needs.
"





On Mon, Oct 10, 2011 at 7:24 PM, Javier Pim�s <elpochodelagente@gmail.com> wrote:
Maybe the way to go is to provide a metadescription of the changes done to the format since last version. That way, you can use it to convert your serialized objects from one version to another (even back and forward). That's what I think databases do, if you update your version, you have to update the database. It seems like a less effort approach.

Cheers!
Pocho.


On Mon, Oct 10, 2011 at 1:50 PM, Yanni Chiu <yanni@rogers.com> wrote:
On 08/10/11 6:03 PM, St�phane Ducasse wrote:
Mariano


No, that's impossible, and if posible, it is not worth it.
Migrating from an old format to a new one is extremelly complicated
and innecessary. The easiest way to solve this is to take the
correct version of Fuel, materialize the graph from the stream,
load new version of Fuel, and seriaize it again. That the easiest,
more secure, and more practical approach I can see.

It would be interesting to see if you can get two different versions
in memory :) (a need for a module system) so that you can load with
one and save with the other.

For the case where a lot of serialized files need to be converted, having two versions in memory is almost a necessity; otherwise, the Fuel code update would have to be applied for each file being converted.

A separate issue is that at some point I wanted to serialize something differently, in two different contexts. In one case, serializing a Pier kernel, I want Fuel to just do its thing. In the other case, when exporting a portion a Pier kernel, I want to fine tune (i.e. map to different objects) the objects being exported/imported. There is a hook to allow the object swap, but the swap would then take place for the other case of serializing to whole kernel (where the desired behaviour was for no such mapping).

--
Yanni





--
Lic. Javier Pim�s
Ciudad de Buenos Aires



--
Mariano
http://marianopeck.wordpress.com