if you look at the xml files, you will see that they are versioned already.
Thank you for your feedback, it's always appreciated. Maybe I can clarify this a little bit on the technical side.
If you take PDF, today its success is often taken for granted, not last because of the weight of the company behind it. But from the beginning, they had a handful of short rules, like "everything should be streamable", etc., and even if you read them now, they are enlightening, for how long ago they were put on paper, and for the foresight they showed.
Of course, RP2 is no PDF and no MP3, but it has a few rules as well. And it has a broader context, an architecture if you allow me to use such an "important" word, where things are meant to fit together. We have worked on XML data to describe configurations for a long time now, and the temptation indeed existed to put such data inside an RP2 file.
If you have Amiga Forever installed, you can see a sample of this XML in paths like "C:\ProgramData\Cloanto\RetroPlatform\Amiga Forever\Catalog" (on Vista). The XML you see there is cross-emulator, i.e. we have a DLL that takes that and converts it to WinUAE configuration data and interactive commands, for example. In spite of that, every now and then we know that we have to add a tag or property, etc., or someone tells us that a configuration has a problem at some point in the game. Or there are new features and possibilities, for example for the dynamic removal of overscan borders, to autodetect copy protection/password requests, etc. Now, how likely is an Amiga game disk to change? Very unlikely, if we look at the existing disk sets. And how likely would configuration changes be? Much more likely, looking back at the evolution of emulators, and the refinements we apply ourselves to the configurations. I am sure this also applies to other users, who have hundreds of carefully-crafted .uae files. The .uae files change much more frequently than the game disks, which remain as released (other than changes during game play, which we can isolate).
Because of this, and also given the number of existing games (as you may know we already cataloged more than 10000) and the compact size required to store the identification "handprints" and the configurations for all existing games, and the likelihood of changes to this data, we opted to separate the game from the configuration. Until you see how many games there are, and how much data this consumes, whether you can reliably identify disks that are almost the same but not quite, whether it's all practical or not, etc., it's hard to decide. But he have the data, we did the homework, so we know how to make it work. This gives long life to RP2 files, and long-time optimal configuration, at a negligible cost. We have shown with 10 games that it works, and we are ready to show it on 10thousand games, making it even simpler and more powerful in the process, also adding tools for people to manage their own images and configuration data. So the value will be in the extra data and tools, and no, we are not trying to reinvent the wheel of game images, for these existing files, on servers or on PCs, will be very easy to rewrap, but wrapping them in RP2 is only part of the goal towards easier playability. And ultimately, it will be up to users to decide whether the sum of this will be worth it or not.
The two version fields you saw inside the RP2 manifest are not a version of the game data (or demo, etc.) This would make the file open to the possible changes which are against the choice of simplicity and long-term stability which I tried to outline here. To the contrary, the two versions are there to make the files even more usable (without changes) in the long term, as well as backwards (with old players), for they indicate two minimum required versions, one for a player, and one for an identification mechanism (handprinting library).
Whether this is all wrong, or "too little too late", time will tell. But for now it's fun :-)
Mike
