littlefs versioning

[guillaumerems]

Hi,

I propose to add a version number to the littlefs lib, for future improvements and new versions.

What about:

#define LFS_VERSION     20180119

int lfs_get_version(void){
    return LFS_VERSION;
}

It will be easier to follow features and issues

[geky]

Hi @guillaumerems, I've been thinking of using GitHub's release tags to mark the current version.

What's the benefit of providing a runtime function to get the version number?

[guillaumerems]

That's true that a runtime function is not so useful, but one benefit I see is that if there is an evolution of the storage scheme between 2 releases, then the library must know it to perform a migration or updates.
So the release could be stored in the superblock attribute

[geky]

Ah, that's a good point. I haven't really thought about how to handle a breaking on-disk change. Although I'm not sure most devices are able to fit two versions of the filesystem in order to make the migration automatically.

The superblock does have a version field reserved, although this is currently just hardcoded to 1.1:
https://github.com/geky/littlefs/blob/1fb6a195206db4927e19fc27372553957da3d515/lfs.c#L2015

I'm thinking minor changes to the on-disk structures can be handled internally in the driver and won't need the user to get involved.

[geky]

Another thought: We will probably need a separate LFS_VERSION and LFS_DISK_VERSION to version the software library and the on disk structures separately.

[guillaumerems]

Agree ;)

[geky]

I put up a proposal over here: #16

Let me know what you think.

I'm thinking I will hold off for now on a runtime function. If it's needed you can always provide it yourself in the same binary unit.