Those will take you to specific links defined in the manifest. As part of a major release of my Google Calendar search I had to create one off upgrade instructions that I mentioned via the releaseNotes key but because the display uses multi text the link wasn’t clickable. Plus it would be nice to include other HTML like bullets, bold, underline, etc.
This is the multi text field I am referring to that doesn’t support HTML:
Is this app being deprecated in favor of Bundle Manager? I installed a new app from Package Manager and was told I need to switch to using Bundle Manager for future updates.
I hate the idea of having multiple "package managers" installed just to do something as infrequent as install apps/drivers.
They are different apps from different authors, though both can ultimately be used for a similar purpose. HPM has, seemingly, a large community following now, while the other apps is newer. I suppose it is TBD where the "market" will take either. (There are actually some feature differences: HPM works directly with app and driver files now, where as the latter works with "bundles," a feature that didn't exist at the time when HPM was created but perhaps would have made things easier and might be able to be retro-fitted into the existing structure. It also doesn't support libraries, which should be able to be added in a similar fashion.)
If you infrequently install apps or drivers--and even if you do so frequently--you don't truly "need" either app. You can do so manually, and especially if the author provides direct links to "raw" URLs, they are fairly easy to either import via URL or copy/paste yourself. The new-ish "Bundles" feature on the hub is also supposed to make this easier for multi-file apps/drivers/libraries--regardless of whether that's you doing it or an app pretending to be you doing it for you (basically how these both work, given no truly "native" support for this kind of thing). 
The fact that installing certain apps from Package Manager (which means there is no problem with them being installed from it) and then having the app tell me I should be using a different packager manager (Bundle Manager in this case) is ridiculous. This is the type of app we do NOT need multiple of. Not only is it bad for the end user who will have to research which one contains what they want to use (if they don't want to install everything manually), but I imagine it would be bad for all other app/driver devs as they will have to keep two package managers in mind when choosing support.
Why does there really have to be a whole new one? It would be better to just add the features to the established app. Can that other dev not submit pull requests with these features?
Bundles are being added to HPM. There's a story there, but doesn't matter much now. Last year, I grabbed a copy of HPM "just in case". I built a Fast Search feature and made it selectable. Last year, I also got Bundles working, at least the easy part.
The first thing to do is migrate people from 1.8.2 from dmeglio repo to 1.8.3 on HubitatCommunity repo. Because of the Holiday I chose NOT to pile update on top of update and am letting the migration percolate out.
As stated above... v1.8.4 is "done, sitting on the shelf" waiting for a large number of HPM users to migrate. I'm itching to release it, but I'm trying to be kind too. 
v1.8.5 will be for Bundles. Bundle Install, Bundle Repair, Bundle Uninstall, View Apps and Drivers are all tested and working. Match Up isn't, and both Update and Modify haven't been tested, because I have to build bundles that would test those features.
The Answer... note the date.
In other words, until this holiday weekend, Bundles were NOT going to get added to HPM. Brian chose, like I did, to invest in getting Bundles to work, but along different paths.
Oh this has been a discussion for a year now? Sounds like "Bundles" is a solution in search of a problem. 
First thing I thought of when I read "bundle" was, how does it manage apps with multiple drivers in which I only need one of the drivers? Like those apps that handle color bulbs, white bulbs, switches, outlets all with a different driver. I would usually only install the specific driver I use. Bundles just sound redundant with less value to me.
But maybe I missed something.
That is a choice made by the author of that "package" (app/driver/etc.), not the creator or maintainer of HPM. If this is important to you, I would suggest providing feedback to the developer who made this choice. Nobody can force an author to use HPM or stop them from using a different solution.
Also, in case you aren't aware "bundles" is a new-ish platform feature that lets you upload a ZIP file to the hub to install apps, drivers, and/or libraries (also new-ish) without needing to add each individually. This is not something HPM or Bundle Manager created, though it looks like HPM will support bundles soon (yay/thanks!). Bundles are very handy for manual installs of multi-file apps/drivers (think of HubConnect, or for me, CoCoHue)--perhaps less so for automated ones like this, but I still think they'll be easier for developers to maintain since it's less HPM-specific work they'd have to do. Very much a solution to an actual problem, IMHO.
Yea, you missed something
Try an Install in HPM, search for "hubconnect" and you'll be offered this:
Click that and take your pick of all the HubConnect Drivers:
I don't know what the original use case for Bundles was BUT for HubConnect it was an answer to a huge support problem. Unfortunately, it didn't arrive in time. Many people couldn't wrap their heads around "Drivers go in Driver Code, Apps go in Apps Code" and many others would just decide that drivers were entirely optional. The product simply wouldn't work under those circumstances.
Bundles can contain Apps and Drivers. Installing them, even without HPM, yields the components landing in the right spot, at the very least.
In my opinion, Parent/Child products are better served by Bundles, because it's fewer clicks and no "parent then child? or child then parent?" install ordering question arises.
For single modules, Import is the simplest, BUT then you run into exactly what you started with.. different methods for different circumstances. HPM targeted exactly that, again, in my opinion.
Thanks for the explanation @csteele , that clears it up a lot. And yeah, I already use hubconnect so I'm aware of that list lol. I remember having to read through that lengthly install doc to get that working.
I have not looked at Bundle Manager because I've been spending all spare minutes either responding in the Community or pounding away at my Typos as I get Bundle support added to HPM.
I think Bundles are and will continue to be low usage. For a developer, they solve a specific set of issues and if you don't have one of those issues, why take the time? But my recent work, be it HubConnect, or Honeywell Thermostat, have all been multi-part and bundles help. Would I build a bundle for Aeotec MultiSensor 6 ?? no.. it would duplicate what HPM is already doing well.
Just want to throw out a big thank you to @csteele for taking on this project.... If you were closer I'd take ya out for some beers!
I'll second that. It's been awesome having it on my hubitat mainly to keep up with app updates.
Really? So far the only thing you KNOW I've done is edit some URLs in one file
I get a beer for THAT??
You reward me for some screenshots??
ProBundles in the middle there.
Yes. . . Most definitely yes!
Thanks...
Here's more evidence for bundles:
If you click Auto_Off you'll get:
Because the Dimmer child is optional. HPM installs both the Parent and one Child... leaving the 2nd child as optional.
Install the Bundle, all 3 components are added. For a lot of people, who don't want to struggle with the terminology, the bundle as a one-shot answer is ideal.
@csteele Can you tell me what the current version is? Mine still shows 1.8.3 after updating, is that correct?
I don't want to confuse by answering in long form BUT the tradition around here is for the "owner" to use the top message in the thread to keep a running tally. Slightly to the right of these words, is "May 26" - click that and you go directly to the first message, where "v1.8.3" is identified as the current release.
Yes, I have discussed, more of a tease perhaps, the next two versions, but I expect it will be the weekend before I release the next. I'm really just trying to give the greatest number of people the opportunity to click on the migration release. Right now, both repos (old and new) are the same. But from here on, I'm only planning to release via HubitatCommunity repos. Thus stragglers would go from 1.8.2 to 1.8.3 using the old repo, which instantly switches them to the new repo, where there would be another update. The hubs don't care, it's the humans that would freak, I suspect Not everyone, but we know there would be some.
* csteele v1.8.4 Migrated to HubitatCommunity
* added txtEnable to silence log.info messages
* use httpS for Fast Search
Fast Search only affects Install by Keyword.
Enable Text Logging is found in Package Manager Settings. Caution: HPM gets VERY quiet with both logging switches off.
Download the Hubitat app
