**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" .
**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.
- 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
[] Remove versions from repo and rely upon build directory, with metadata in that directory and git tags to signify previous versions
[] Upgrade test suite will need to be revised accordingly
[] Make example/docker-compose.yml 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.
[] 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
[x] Consolidate configuration values in example and in tests suites to rely upon values from env vars vs in scripts or in the the compose override files
[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)
[x] 🚨 Rename QS_* to QUICKSTATEMENTS_* to match naming used in Docker files, and reduce confusion with WDQS_* variables
[x] 🚨 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).
[x] 🚨 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