On Tue, Aug 28, 2007 at 05:47:11PM +0200, Carl-Daniel Hailfinger wrote:
a major/minor version in the LAR header?
I generally hate versions. Think features, not numbers.
but then you have to handle the versioning, and figure out what to do if it does not match, and .... Let's not do this.
We simply could reserve some space at the end of the header and use that for future extensions without having to change a version number. Only if the extension needs changes in earlier fields of the struct we would have to change the MAGIC.
This works!
On Wed, Aug 29, 2007 at 10:04:26AM +0200, Stefan Reinauer wrote:
Interoperability between different lar versions seems to be the quest for finding the best method of shooting yourself in the foot. Definitely a big issue and you can spend a looot of time on getting it done right.
It has surely been done many times before.
On Wed, Aug 29, 2007 at 10:12:24AM +0200, Stefan Reinauer wrote:
if (lar_version > my_version) { printf("Your image is too new. upgrade lar utility\n");
if (lar_version > my_version) { printf("Your image is too old. downgrade lar utility\n");
if (lar_version != my_version) { printf("Your image version and lar utility version do not match. Change either\n");
Anything beyound the above is a waste of precious time imho. Let's not do migration paths for pre-pre-pre-pre-pre-production software.
Agreed - but the sooner we decide on a nice upwards compatible protocol the sooner it becomes production software. ;)
Your suggestion is pretty similar to what BitTorrent uses and that works fine. One bit per feature or even one bit to active a separate extension protocol.
//Peter