Accept forwards compatibility about dwarfs HOT 4 CLOSED

That's a very fair point.

The current behaviour of simply ruling out forward compatibility upon any change that could make an older binary fall over was just out of simplicity.

Maybe its because of the new metadata method?

That and the new compression algo. The metadata change is in fact not forward-compatible because older Linux binaries wouldn't be able to properly handle images containing symbolic links created on Windows.

In any case, going forward I'm going to adopt "feature sets". As long as newer binaries create images using features that are a subset of the feature set provided by an older binary, the older binary will be able to load them.

from dwarfs.

cool

from dwarfs.

Okay, quick update on this one. If anyone thinks any of this is a bad idea, please let me know :)

I'm planning to push out a 0.7.3 release soon™. The only differences relative to 0.7.2 will be that it's going to be a lot more relaxed about section types and compression types it doesn't know, and that it will understand the concept of "features" with an initially empty feature set.

Being more relaxed about section / compression types means that 0.7.3 and later will be able to read images produced by newer versions of mkdwarfs as long as there's no change that requires a file system version increment. For example, the 0.8.x series will introduce a new "history" section type that is irrelevant for accessing the contents stored in the file system and can safely be ignored. 0.8.x will also introduce FLAC compression, but as long as you're not actually accessing files in FLAC compressed blocks, 0.7.3 will be able to mount and use a 0.8.x image just fine. If you actually access data in a block using an unsupported compression, you'll get an I/O error. I think this should make for a much smoother upgrade experience. As long as you're not immediately using all features of a new release, you'll still be able to use new file system images with older versions.

Even the 0.8.x series will very likely not be adding any features to the feature set. These are reserved for cases where new (optional) features would make it impossible for an older release to reliably read a new file system image. For example, if a new release would add further encoding/decoding on a per-file basis (e.g. using something like brunsli), this would become a "feature" and DwarFS versions not supporting this feature would reject to load an image that was actively using this feature. Again, this means that "you don't pay for what you don't use" and as long as you don't use the feature, older binaries will still happily mount new images.

from dwarfs.

Fixed in v0.7.3.

from dwarfs.