The basic strategy is to have multiple update sites:
- A more-or-less current one, which has the most recent plugins, plus perhaps a few of the older releases
- Older plugin site(s) (not too many) which contain ranges of plugins
A typical imagined timeline would be
- A subsite is started (e.g. ruta, or uimaj)
- Releases occur, and plugins are added at some version level
- After some number of releases, a decision is made that the repo is getting too big.
- The old repo is renamed with a suffix indicating the range of versions in it. For example,
the "uimaj" repo might have a name uimaj-2.3.1-2.10.1.
- A new repo is created, with just one (the latest version), and is deployed.
The uima website
documentation indicates where to find older eclipse plugins (the Apache archive site, following the
the naming conventions: uima/archive-eclipse-update-site/subsitename/subsitename-x.x.x-y.y.y).
- After confirming that the renamed old site is visible in Archive, then it is deleted on the main release site.
After this is done, the new subsite will have just the latest version in it,
and would then be added to over time, with additional
releases. When it gets too big, the same procedure is repeated, with a new named update site .../---subsitename.u.u.u-v.v.v
with another range set being created and archived.