pio lib show 2869
Arduino Library for ams (taos) luminance chip Tsl2561 with autogain
Version: 2.0.1, released Thu Feb 15 18:23:47 2018
d668ce8da7, released Sun Feb 11 00:34:05 2018
2.0.1, released Thu Feb 15 18:23:47 2018
Maybe it is related to the weird first version tag? I don’t mind it being removed.
Would be great if there is a notification with some kind of error log to the lib owner in such cases.
Not in a hurry though, just want a great tool get even better
That was the issue with the library maintainers. They forgot to update library.properties version. The source files of the library were actual. Nevertheless, I’ve just updated that library. Now all manifests are up to date.
Hi, it seems I have the same problem.
I registered my library PlatformIO Registry (version 1.0.5).
The following updates ( newest version 1.1.1) were not adopted although the new version ist maintained in the manifest:
the library.json in the 1.1.1 tag points to a 1.1.0 release - maybe it’s confused with the mismatch? Which could also explain why 1.1.0 isn’t showing in the release history on the PIO registry.
it’s possible the tag should be v1.1.1 - although a re-read of the documtation suggests both forms are acceptable, so maybe it is just the first point, or the PIO Library Crawler needs a kick to liven it up.
Try changing the version number to 1.1.2, and ensuring that version of library.json is tagged 1.1.2, and then wait 24-48 hours to see if the change goes through. The PlatformIO Library Registry is showing the current library.json manifest, so it is at least seeing that properly.
Fantastic, looks like the crawler just got confused with the tag/version mismatch. It’s easily done… still working out this git stuff myself at times… just found out the other day that I don’t need to merge branches (I use a master/develop two branch system) when using tags, meaning I don’t get the extra merge commitsnow … I can just tag the final commit for a version, and then merge that tag across…
Basically, for elapsedMillis, I have two branches … develop and master. I only release new versions on the master branch, and the develop branch is where anything cues up in the meantime. It’s not a model particularly needed for this library, but it lets me practice with git and github on methodologies that would suit larger or more multi-developer projects.
What I didn’t like about this was the fact it seemed you needed to merge back and forward… i.e. have a look at the commit logs for platform-atmelavr as one example. Stuff happens in develop, then gets merged to master, and then master gets merged back into develop. I thought there had to be a better way. I then realised when in the develop branch, and you’re tagging a commit as the final commit for a release (i.e. v1.0.5), you can push that tag to another branch… i.e. master… and no merge commits, nada. And since master is really a snapshot in time of develop, there’s no need for the merge back.
That’s the theory for now, unless someone says that doing it this way will cause me headaches or grief in the future.