Addin Auto Update choices codified in addin.def

[nathan-clark]

What inspired this wish list request? With JMP19 on the scene, I noticed an auto update feature for addins where JMP will look for udpates to files from an 'install folder'. The implementation was a bit "clunky" and ends up breaking a bunch of infrastructure we already had built.

What is the improvement you would like to see? Rather than living in the Views > Addins settings, these choices should be codified in the addin.def file all addins need. It will make it easier for those with existing infrastructures to manage as well as easier to implement part of JMPs cool features iteratively.

Why is this idea important? I want to take this feature to the next level. It's a super great idea, but its current implementation can easily cause issues for others. In my current infrastructure, updates are checked for against a master list to know when new versions are released. JMP's feature could deprecate the need for some of this, but it needs more finesse in how it's laid out. Some examples:

1. Addin installed from correct location, all is well... later on user can't access location and needs the update. I pass along the jmpaddin file to them so they can keep on going. They drag it into JMP ... now it's possible the install source is now the downloads folder and they wouldn't get notified of updates because of that change ... hard coding the correct source into the def file would allow this to work regardless.

2. Testing addins. Similar to #1 if you have a folder where your tests are located, installing a test file would change your install location to the test location and they wouldnt get notified when a new prod release happens. And depending on how files are named they may or may not be notified of new test versions ... because test versions are often 'handed' off, they include teh version in the filename... so an exact filename match isn't possible for the update checks.

In both of these examples, there are aspects of what JMP has done that could be useful, but the deployment team needs more control in how their addins shall be marked for update. There are probably more example, but I think this is enough to get the ball rolling for the update 'stuff' to be part of the addin.def file with one or more variables there.

Thanks!

[hogi]

Thanks @nathan-clark for highlighting the issues.

How is the speed of the new approach compared to "updates are checked for against a master list " [like in  Add-In Manager by @Justin_Chilton ] ?

[nathan-clark]

I haven't done any speed tests yet, @hogi. Mostly I've just been annoyed because it's been creating issues with my other deployments. I suspect speed would be faster overall since it appears JMP just checks for a new modification of a filename vs my comparison against actual build release dates. Speed will also be determined based on the 'source' folder being referenced by JMP.

[Sarah-Sylvestre]

Thank you for taking the time to share this request! This is great feedback. 

[hardner]

@nathan-clark Can you point to documentation of this feature and the current implementation?  I don't understand what that implementation entails and I'm failing to search out anything about it. Are you saying that JMP is looking in the folder the user originally opened the .jmpaddin file from? And then what is it that it looks for there? any .jmpaddin files with different filenames but the same addin id in addin def?  or something about the addin version in addindef? or same filename but some change to the content?

[nathan-clark]

@hardner I am not sure there is any documentation. The information I have has come from my own testing/observation and a support thread with JMP support when I noticed JMP 19 asking me questions about checking for updates with some of my addins.

And yes, if you go to View > Addins you should be able to see some of the items i've described ... you should see an "Install Source" section as well asn an "Update" drop down list ... if the dropdown is set to "check for updates..." JMP will monitor the install folder listed, and it's not easy to or possible to change - yet.

How JMP monitors, I am not sure of. I am guessing either a same name .jmpaddin with a newer modified date? But I could be wrong ... My main ask is around controlling some of the pieces.

1. I aldready have auto update infrastructure so I don't want JMP to monitor anything and I want that set by the addin itself, no user choice
2. If I do want JMP to monitor, I want to control how JMP monitors for updates -- like force monitor a PROD folder which would allow the user to upload test .jmpaddin files w/o affecting monitoring PROD

Being able to codify this through the addin.def makes the most sense to me... and if a user truly wants to override the View>Addins is still available. But the current implementation, whatever the background rules are, breaks aspects of the infrastructure I aldready built and use for deployment of my addn suite.

Does that help?

[hogi]

Auto-enabling the Update by default (via a setting in the AddIn) for company AdDIns will be a GameChanger !

So risky that A user forgets to activate Update function - and thereby suffers from being stuck with an old version.

A setting in the AddIn is much better than a setting in the local preferences. How to guarantee that 100 out of 100 users activate the feature in the local preferences.

[hogi]

From our experience:
- a file with the same name is monitored
- update is triggered when the file is new (even if the version is not changed)
- changing other files in the folder doesn't affect the mechanism

benefit comapred to UpdateCheck@AddInManager: 

-multiple AddIns can be updated synchronously
- silent mode (although I don't dare - nice to know which AddIn gets updated)

[nathan-clark]

Conversely, I want 0 people to use the autoupdate feature ... until I have 100% control on the other aspects of autoupdating :) 

[hardner]

Thanks @nathan-clark and @hogi.  I did make my own support request for details about this.  I'm in complete agreement in wanting control over options around this behavior.

[hogi]

so, if @nathan-clark wants control back - disallowing to manually select the option, then a "force settings" will be helpful.

For my case, some selection for the default setting will be sufficient.

When AddIns are installed from Sharepoint, synchronized to local OneDrive,  every user will have their own Install path.
When installed from a network drive, it might be beneficial to force the "auto-update" to stick to a default path.