**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
- Create tasks for completing the agreed upon solution.
---------
**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
---------
**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.
[] 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.
[x] ⚠️ 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_URLs and standard *_URLs (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.mds 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 READMEs for details or directly documenting there