Currently the release process for wdqs is error prone. Note that `gui` is a maven submodule **and** a git submodule.
# take master of `wikidata/query/rdf` locally
# bump the snapshot version (e.g. 0.3.4-SNAPSHOT -> 0.3.5-SNAPSHOT)
# push to gerrit a change for this to `wikidata/query/rdf` and `wikidata/query/gui`
# merge the gerrit patches
# run mvn to deploy the artifacts to the archiva repository (snapshot)
** This will generate the zip distribution containing both the server and the gui used by https://github.com/wmde/wikibase-docker for wdqs related images
To prepare the deployment of the server side components we must use the `wikidata/query/deploy` repository:
* delete the old snapshot and add the new ones for the `blazegraph-service` and `lib/wikidata-query-tools-X.Y.Z-SNAPSHOT-jar-with-dependencies.jar` artifacts, example commit: https://gerrit.wikimedia.org/r/c/wikidata/query/deploy/+/550342
To prepare the deployment of the client side components we must use the same `wikidata/query/deploy`repository:
* bump the `gui` submodule to the commit ref we want to deploy (e.g. https://gerrit.wikimedia.org/r/c/wikidata/query/deploy/+/549831)
The problems of this procedure are:
# There are no guarantees that the version in archiva matches what is committed in the git repository, since we push to archiva on the same working copy as the one used to bump the version there are no guarantees that the version bump commit does not become a merge commit once validated in gerrit or worse being rebased after the fact.
# `gui` being a git submodule of `wikidata/query/rdf` is confusing and error prone, the gui is being developed on its own repo but when bumping the snapshot version of `wikidata/query/rdf` we create a separate commit for it. Meaning that this repo has two independent sources of changes.
There could be two strategies to strengthen the release process of this project and both of them requires getting rid of the `gui` submodule.
===== A single repository =====
Move the `gui` project directly inside `wikidata/query/rdf`.
* pros:
** A single unified release process for the server and the client and the zip distribution managed by the maven release plugin
* cons:
** needs to release everything if either the gui or the server needs an update (already the case today for the zip distribution)
** git history is lost on the `gui`
** find solutions for the deploy preparation:
*** unclear if scap is able to do some preparation (unzip a file prio to deploying). The gui would be available as jar file from archiva
*** if scap is not able to do this we still need a `gui` submodule and have it updated to the tag created by `maven release`The preferred solution would be to separate completely the gui from the query/rdf project.
===== Separate repositories =====
Remove the `gui` submodule from `wikidata/query/rdf`. See also {T235639}.
* pros
** independent release processes for the gui and the server (which reflect reality of the development)
** can use the maven release plugin for `wikidata/query/rdf` and have real versions
** unchanged deployment preparation on `wikidata/query/deploy`
* cons
Open questions:
** requires a new repository to manage the distribution of the zip file that contains- decide how the zip distribution should be managed, should we just provide a zip for the updater and the war for server side components? Or should we continue to provide a zip with server side and UI components.
** 3 steps release process:- please add more
related tickets:
*** server, gui and the zip distribution- {T235639}
- {T192006}