Your PackageManifest.json is identifying both an App and a Driver are part of the package but that the app is "empty".
"apps": [{}],
"drivers": [{
"id": "3c0691d0-2094-4ae7-a603-d3d32cc28e5c",
"name": "My Location",
"namespace": "myLocation",
"location": "https://raw.githubusercontent.com/wecoyote5/hubitat-MyProjects/main/MyLocation.groovy",
"required": true,
"oauth": false,
"description": "Driver to support Lat/Lon updates from HD+."
}]
Just get rid of the empty "apps": [{}], line(s).
Because the "apps": word is in the manifest, then HPM checks for an app and any updates to the app. But the values are all empty, and so it falls into catch-22 type of logic. If your Package doesn't have an App, then don't half define one. Same for Drivers, if the package is an app only, don't half define drivers.
Simply do a Repair on HPM. The cosmetic typo has no effect, so you're welcome to just ignore it.
It's a result of how I manage the source I'm working on. When I publish a release, I predict-the-future and get the source ready for the next release. The prior release was 1.8.11 and I predicted that 1.8.12 would be the next.. then the bigger issue was found and I felt it needed a bigger increment. 1.9.0 I caught it in 2 of the 3 places If you looked at my source today, it would show 1.9.1 because that's the size of change I'm predicting We will have to see how well I did...
I have some parent child apps, often I will only be updating a Child App. Is the release notes section only supported at the package level, or is it possible to have release notes for each of the modules within a package?
Also, do you have any advice on versioning of package\parent\child\driver apps.
Let's say I do an initial release and everything is at V1.0.
Now I find a bug in a child app and I rev that child app to V1.0.1.
Should I always rev the package version with any change to the contents? Or do I only rev the package when I add or delete something from the package?
Thanks, great app and thanks for supporting it. Makes things a lot easier.
HPM simply displays the Release Notes. It doesn't use them. And I think the hint is that it's a "Package" manager If 10 items are a Package, then there's one Package Manifest and within, one Release Notes, and so on.
I understand 100% how "we developers" organize and revision our code, but HPM isn't focused in that direction. It's Package oriented not component oriented. HPM does not look into the code itself, it strictly uses the Package Manifest to identify a package that needs updating.
You need only update Package Manifest (whatever you actually name it) to cause an Update. As an extreme example, you could revision your components as v1.0.6 + 1.2.4 + 0.1.2 and so on, for each component.. then in the Package Manifest, revision it as v1000.4.a -- where the relationship is entirely obscure to me... you'd understand it, and the package users wouldn't care. I understand in this example it's MORE difficult to organize, but I'm hoping to clarify the 'no relationship' that actually exists between the code version within the code and the version in the Manifest.
Personally, I update Parent/Child apps independently and when I have a child only code update, the entire package is updated, because a "Package" is the smallest granularity of HPM. (Ignoring Modify, which focuses on components.)
So HPM is only looking at the versions on github and local hub and doing a string compare? If the strings are different then it's an update? The actual version strings are just for us humans.
If the package version changed but none of the Apps or Drivers versions changed would HPM still indicate there was an update available? I'm thinking maybe I'll just go with a perpetually increasing integer for the package version to break any appearance of connection with the app versions.
For Update, HPM loops through the installed Packages, reading in the PackageManifest.json for each, comparing against the internally stored data. (state.manifests)
But it's just a string compare right? As long as the "manifest" version string is different from the "installed" version string it will prompt that there is an update? I could go from 1.4.2 to a.b.c and it wouldn't care?
Same for Drivers, if the package is an app only, don't half define drivers.
We will have to see how well I did...
