Updating dvwebloader

[DonRichards]

Document how production installations should be updated

The README currently documents multiple ways to use dvwebloader, including pointing Dataverse directly at the GDCC GitHub Pages deployment:

curl -X PUT \
  -d 'https://gdcc.github.io/dvwebloader/src/dvwebloader.html' \
  http://localhost:8080/api/admin/settings/:WebloaderUrl

It also recommends using a fork or locally hosted copy for production, but it does not explain how administrators should update those installations when a new dvwebloader version is available.

Could the documentation include an explicit installation and upgrade strategy for each supported deployment method?

Suggested topics to document

GDCC-hosted GitHub Pages deployment

Please clarify that:

• No local update is required.
• Changes published to the GDCC GitHub Pages site can become available to Dataverse users automatically.
• The application code is loaded and executed in the user's browser.
• This method is primarily intended for testing, demonstration, or environments that accept upstream-controlled updates.
• Production administrators should understand that the deployment is not pinned to a release, tag, or commit.

Locally hosted deployment

I'm making an assumption that this is actually the process for updating locally.

Please document a recommended upgrade process, such as:

1. Select a release, tag, or reviewed commit.
2. Download or clone that revision.
3. Copy the src files to institution-controlled web hosting.
4. Run localinstall.sh if remote JavaScript and CSS dependencies should also be hosted locally.
5. Test the new version against a staging Dataverse installation.
6. Update the deployed files or change :WebloaderUrl.
7. Retain the previous version for rollback.

It would also help to clarify that localinstall.sh vendors remote JavaScript and CSS dependencies, but does not update dvwebloader itself.

Versioning clarification

The documentation should also identify the authoritative source for the current version.

For example:

• Is the GitHub Pages deployment associated with a specific release?
• Should production installations use the latest GitHub release or the latest commit on main?
• How can an administrator determine which version is currently deployed?
• Are release artifacts expected to be created for every user-facing version?

A small table could make the behavior clearer:

Deployment method	Who controls updates?	How updates are applied
GDCC GitHub Pages	Upstream maintainers	Automatically when the hosted site changes
Forked GitHub Pages	Fork owner	Merge or pull upstream changes
Local hosting	Dataverse administrator	Manually deploy a selected release or commit

The current installation options are useful, but documenting the update and rollback behavior would make the production implications much clearer.