**Context:**
It is strange that we require users to clone the pipeline to then copy the "example" directory in order to run the Wikibase Suite "example".
Do we want to still consider this the "example" or is it correct to call it a "distribution" or better yet "Reference Implementation" .
There are not clear instructions, and potentially adequate setup, in our example configuration for moving it into production (`https` configuration and/or a proxy server?).
**Proposal:** Move our distributions (the "example directory") to its own home (github? tbd), and clearly version each release including a semantic versioning scheme which tracks in some informative way against MediaWiki and/or Wikibase versions. This is the most critical step we can make to clarify and streamline our installation, and maintenance/upgrade process. This will also help to set things up to better focus and "tidy up" the build pipeline repository" itself, allowing us to get focused and produce better and more reliable distributions. (See T343349)
**Acceptance Criteria:**
- Consider this proposal, and any others as a team, and come to decisions.
- We know how to test and have tested the distribution on an actual Internet-facing VPS and identified any actual or potential issues in doing so
- How we communicate to the community about it and its implications for our users should be part of the discussion
- From the topics to tackle and decide:
- which ones need to be tackled now and create tasks for completing that work
- which ones we want to get to at a later point in time and create tasks for these too
- which ones we want to let go
---------
**Goal:** Create a clear and more formal Wikibase Suite Distribution story.
Some things we may want to do:
[] Deprecate the "base" Wikibase image in favour of only distributing `wikibase-bundle`.
[] Change `example/docker-compose.yml` to run all services, and create a new optional `docker-compose.minimal.yml` which inherets service definition from example/docker-compose.yml, deprecating `example/docker-compose.extra.yml`
[] Consider moving extra-install.sh into Docker/Wikibase
[] 🚨 Make Github versioned release packages of what currently goes in the example directory
[] 🚨 Consider moving these releases to a new Github repo called wikibase-suite (i.e. wikibase-suite/releases)
---------
**Goal: ** We want to make the upgrade process easier for users. As part of that we want to improve clarity in configuration of our distributions (Suite and individual Docker images), as well as code readability and maintainability.
Some things we may want to do:
[] Rework the configuration so that it's on one place and editable by users
[] Clarify and normalize use of `default.env`, `template.env`, `local.env`, and `.env` in both the distribution and build pipeline/test contexts to enable making env var naming consistent.
[] ⚠️ If there are two Environment Variable names in two places that are set to the same value anywhere in the code, and have the same purpose, decide on one naming and apply that throughout
[] 🚨 Rename all `*_SCHEME_AND_HOST` env vars to be `*_URL` (and `*_SERVER` when protocol is not expected to be at the beginning):
[] Remove hard coded “http” anywhere but in environment files in preparation for HTTPS options
[] 🚨 Clarify `*_PUBLIC_URL` vs internal `*_URL` and carefully consider naming:
[] If a full server URL or server name+port is particular to the Docker network, vs what must be public. In the distribution this should be further clarified.
[] Consider optional `*_PUBLIC_URL`s and standard `*_URL`s (e.g. `WIKIBASE_URL` and `WIKIBASE_PUBLIC_URL`, with only `WIKIBASE_URL` required)
[] 🚨 Rename QS_* to QUICKSTATEMENTS_* to match naming used in Docker files, and reduce confusion with WDQS_* variables
[] 🚨 Rename `WB_PROPERTY_NAMESPACE` to `QUICKSTATEMENTS_PROPERTY_NAMESPACE`, etc. These variables are specific to Quickstatements which is only a Wikibase service (vs Elastic Search, etc).
[] 🚨 Make all `MW_WG_*` variables to be simply `MW_*`, unless there is a compelling case for keeping the WG
[] 🚨 Create an “Upgrading from X to Y version” in `example/README.md` and relavent `Docker/*/README.md`s detailing the environment variable name changes
[] 🚨 Note the change of some public-facing env var names under a “BREAKING CHANGE” note in `CHANGELOG` for this version, either pointing to the related `README`s for details or directly documenting there