Write a Maven-based update site generator

[ctrueden]

A Maven-based update site generator could produce db.xml.gz files for artifacts available from a remote Maven repository. So e.g. we can generate an update site for Fiji by running the generator against sc.fiji:fiji. It would scrape the maven-metadata.xml for all release and snapshot versions of Fiji, and declare them in the db.xml.gz. It would declare the dependencies to match the declared deps of that GAV (need to check whether the Updater is smart enough regarding transitive deps, though—I'm guessing it is).

• For stable, use release versions only. For unstable, use the latest SNAPSHOT.
• There might be a problem with old snapshots disappearing: rerunning the generator after a snapshot has disappeared would (naively) make that version no longer declared in the db.xml.gz. But we can get around this by supporting unioning of existing db.xml.gz metadata with newly generated content.
• Because we have datestamps for all published Maven artifacts, we should be able to support downgrading in a future version of the Updater.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/omero-plugins-in-fiji-compatibility-with-imagej-omero/70248/2

[ctrueden]

Revised thinking:

• The Maven-based update site generator generates a suite of related update sites, one per GAV. Each update site knows all versions of all artifacts, but lists the ones for that version as the current versions, and all others as "previous" ones. In this way, by switching update sites, users can freely upgrade or downgrade to desired versions aligned with the Maven G:A:V coordinate. Furthermore, we can have a rolling latest symlink (perhaps sites.imagej.net/Fiji itself?) pointing to the latest release, and a stable symlink (perhaps sites.imagej.net/Fiji-Stable?) pointing to the current declared stable version.

• For deciding which releases of Fiji are "stable", we can do it similar to how Debian does, where as a community we decide a particular Fiji release is good enough to bump into the stable update site, after it has acted as latest for a sufficient period of time without catastrophic issues occurring.

• A potential downside to the delayed labeling of latest versions as stable is that there might be a need to push security bug-fixes more rapidly without accepting all of latest as a new stable. I am concerned about this scenario requiring backports from main to a second stable integration branch—we would rather avoid the need to do things this way, but it might not be avoidable while maintaining good security for Fiji-Stable...

• The upside of this approach is that we would not need to create a separate sc.fiji:fiji-stable artifact (although we could if it's helpful), but rather merely have a manifest somewhere identifying which versions of Fiji have served on the Fiji-Stable update site track.

• A different solution could be the Linux kernel versioning approach where even minor digits are stable and odd minor digits are latest, the idea being that we always converge an odd version back to an even-numbered release again once the odd version is behaving well enough. This could work as long as we stay on top of things to resolve disruptive changes quickly, so that we can rapidly respond to security issues by pushing out new stable releases.