littlefs-project / littlefs

A little fail-safe filesystem designed for microcontrollers
BSD 3-Clause "New" or "Revised" License
5.22k stars 799 forks source link

Where do we find the version in the code #984

Open Rasmus-Fink opened 6 months ago

Rasmus-Fink commented 6 months ago

Where do we find out which version we are using? I do not see any references from the version number tagged in git to define/consts in the code. As an example we may have 2.5.xx but since we can't see the patch number, but can't know if an update would fix any issues.

It is possible to add the tagged version number to lfs.h? Even a simple comment would be very helpful :-)

Please?

BR Fink

geky commented 4 months ago

Hi @Rasmus-Fink

This is not currently committed into the codebase. The patch numbers are informative, but the concern is committing them into the code would create a large amount of commit noise.

With git, the commit hash provides much more info than a patch number ever could.

Or if you copy the littlefs source into another codebase, you can always add the patch number/version to the relevant commit to help track what the most recent patch version was. This is what we do in littlefs-fuse (example).

Rasmus-Fink commented 4 months ago

Ok. The trouble is that we use the version that ST included with their CubeMX stuff and currently we have NO way of telling from the source code what version we are using... There is only a define: #define LFS_VERSION 0x00020005 -which does not tell us much...

Should you ever consider using a version number that you update when to create a new tag, then that would be highly appreciated :-)

Thanks for the reply :-)

geky commented 4 months ago

Hmm. I'll have to think about this. It's a good point many users don't control how they get a copy of littlefs. Maybe the onus is on CubeMX to provide this?

Some of the problem is littlefs patch releases can be as small as one or two commits. We don't really want to force patches to be bigger, since it's good to get bug fixes out quickly, even if small, but the more overhead involved in a patch release the more things slow down...

In the meantime this command should be able to find the relevant patch tag if you check out littlefs locally:

git describe --contains $(git log --find-object $(git hash-object ../my-copy/lfs.c) --reverse --format="%H" | head -1)

Or if you just want the commit hash:

git log --find-object $(git hash-object ../my-copy/lfs.c) --reverse
Rasmus-Fink commented 4 months ago

Hi again, Thanks for at least considering it. As I see it a patch release does not have to be big. The main thing is that a bug gets squashed when found. I don't know what numbering scheme you are using, but if you use semantic versioning 2.0 (https://semver.org/), then it should be more clear that a patch number does not need to be big - as long as the version number gets updated. BR

bmcdonnell-fb commented 4 months ago

@Rasmus-Fink,

we use the version that ST included with their CubeMX

How do you get LittleFS from STM32CubeMX? I don't see it.

image