Page MenuHomePhabricator

Define a release process for wdqs
Closed, ResolvedPublic


Currently the release process for wdqs is error prone. Note that gui is a maven submodule and a git submodule.

  1. take master of wikidata/query/rdf locally
  2. bump the snapshot version (e.g. 0.3.4-SNAPSHOT -> 0.3.5-SNAPSHOT)
  3. push to gerrit a change for this to wikidata/query/rdf and wikidata/query/gui
  4. merge the gerrit patches
  5. run mvn to deploy the artifacts to the archiva repository (snapshot)

To prepare the deployment of the server side components we must use the wikidata/query/deploy repository:

To prepare the deployment of the client side components we must use the same wikidata/query/deployrepository:

The problems of this procedure are:

  1. 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.
  2. 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.

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.

Open questions:

  • 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.
  • please add more

related tickets:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
A single repository
  • cons:
    • git history is lost on the gui

I don’t see why – there are ways to merge git histories of multiple repositories, it should be possible to include the gui history for that directory.

I do think separate repositories is the way to go, though.

I would be in favor of separating the repos for two reasons:

A lot of the release process has been automated. We should review the current automation and document it on wiki. That's sufficient to declare this done!

Gehel triaged this task as High priority.Sep 8 2020, 7:21 PM
Gehel claimed this task.

Documentation is good enough for now, it is going to be further improved organically as needed.