[
https://issues.apache.org/jira/browse/UIMA-6443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-6443:
---------------------------------------------
Component/s: Build, Packaging and Test
> Fresh Eclipse update site for every release
> -------------------------------------------
>
> Key: UIMA-6443
> URL: https://issues.apache.org/jira/browse/UIMA-6443
> Project: UIMA
> Issue Type: Improvement
> Components: Build, Packaging and Test
> Reporter: Richard Eckart de Castilho
> Assignee: Richard Eckart de Castilho
> Priority: Major
> Fix For: 3.4.0SDK
>
>
> we have recently been reminded that cleaning up old releases from our website
> would be a good thing.
> https://issues.apache.org/jira/browse/UIMA-6427
> I have done that for the source/binary releases, but the question how to
> handle the Eclipse udpate sites is still somewhat open.
> It seems that currently, our Eclipse update sites contain multiple releases.
> I.e. whenever we do a new release of the UIMA
> Java SDK or UIMA Ruta or such, the existing update site is checked out from
> SVN, the new release is added to it, and then
> the updated site is committed back.
> When I speak of "update site" in this mail, I actually mean the "sub-sites"
> we maintain for uimaj, ruta, uima-as, etc. and
> *not* the generic top-level "composite update site" that is usually not
> touched at all during releases.
> We have a process described on the website to regularly "archive" update
> sites and start them freshly:
> https://uima.apache.org/dev-eclipse-plugin-archiving
> But this is something raising the question of: when should we "archive" the
> update site?
> I believe things would be cleaner if we didn't update the update sites at all
> but instead *always* archived the
> previous update site and created a fresh update site with every release.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
