Decoding and backwards compatibility

[ikerr]

This is more of a question than an issue, so I apologize if there is a better place for this.

If we use the Draco encoder and store the output, we'd like to ensure that we are able to decode that output at a later date. But what if the Draco file format changes in a future update?

1. Will future versions of draco_decoder.js handle backwards compatibility, or do we need to ensure that we are using a version of draco_decoder.js that corresponds to the encoder?

2. In the latter case, should we store draco::Version() with our encoded geometry and then select the decoder with the same version?

I also noticed that there is a hard-coded "file format" version (1.1) here:
https://github.com/google/draco/blob/master/compression/encode.cc#L30

However, I don't see any way to retrieve that version in draco_decoder.js.

3. Are there any plans to provide a function in the encoder that returns the "file format" version as opposed to the Draco version (i.e., draco::Version())?

4. Would it make more sense to use the "file format" version to determine which decoder to use vs. using the Draco version (i.e., draco::Version())?

Thanks!

[ondys]

Will future versions of draco_decoder.js handle backwards compatibility, or do we need to ensure that we are using a version of draco_decoder.js that corresponds to the encoder?

For most updates, we plan to maintain backwards compatibility (that is, newer versions of the decoder are going to be able to decode files that were encoded in the previous versions of the encoder). The opposite (forward compatibility) is not going to be maintained though (older decoder is not going to be able to decode data encoded with newer encoders).

Saying that, there may be occasionally releases where we decide to break backward compatibility but these should be rare (if ever) and they would be clearly announced.

We may introduce options to build decoder without maintaining backwards compatibility that can result in smaller binary/javascript sizes though.

In the latter case, should we store draco::Version() with our encoded geometry and then select the decoder with the same version?

That shouldn't be necessary, the version encoded in the bit-stream is always going to be updated when we introduce new features. The current plan is to increase the minor version when we maintain backwards compatibility and to increase the major version when the backward compatibility is not maintained.

Are there any plans to provide a function in the encoder that returns the "file format" version as opposed to the Draco version (i.e., draco::Version())?

I've added this to our internal issue tracker. We will add support for retrieving file format version from the encoded bit-stream to draco_decoder.js + functions to query it on the encoder side.

Would it make more sense to use the "file format" version to determine which decoder to use vs. using the Draco version (i.e., draco::Version())?

Yes I think using the "file format" version would be better as it is already included in the bitstream

[FrankGalligan]

I'm closing this issue. If you think we should talk more about it please re-open.