I’d like to be sure, that understand right your doc. Is version field mandatory to force crawler scan git tags? I’m a bit confused with this logic - why version numbers should be duplicated in library config if tags already available?
If a version field is not defined, the latest commit will be considered the latest version.
If there is a version field, but not matching tag, the library crawler will consider the latest commit at the time of seeing that version for the first time as the code for that version, and will ignore further commits until the version number changes.
If there is a version field AND a matching tag, then the tagged release will be considered the code for that version.
I won’t presume to know @ivankravets exact reasoning for this methodology for implementing it this way, but I would hazard a guess is that it’s because of the many different ways people can specify versions of code, and not being a mind reader as to what constitutes the latest version of the code. Semantic versioning (as is recommended) would make this possible, but you can’t force people to use it. So specifying it in the library manifest - be it library.json, library.properties or module.json it is. This also means the version number travels with the library should it ever be downloaded from whatever version control system its on, allowing for update checking of the downloaded copy.
1 Like
Yes, you described everything correct! Thanks!
The new PlatformIO Registry will provide an UI where you can submit your library manually or via pio lib publish. So, you will personally control this “updating” process.
1 Like