== Current situation ==
- c- Currently wmde11 for example is tied with the onversions like `wmde11` are a suffix to the mw version that isey are built in iton
- users don't get any "meta info" based on the current numbering
- the current versioning scheme does not communicate breaking changesNOT
- the current versioning scheme does not allow updating on a stable channel to get security fixes but prevent - communicate breaking changes
- the current versioning scheme does not allow to name builds from upstream main branches (T343692) - allow updating on a stable channel to get security fixes but prevent breaking changes
- the current versioning scheme does not - provide an obvious way to communicate security fixes in dependencies while the MW version stays the same
- allow naming of cutting edge builds off of the upstream main branches (T343692)
== Ideal situation ==
- we- We want to focus on how users see the versioning scheme: they need to be able to tell a major version release from any other one
- they need to be able to distinguish major versions from minor versions
- they need to see whether a version includes breaking changes or not
- b- Building using a certain version of the pipeline should create the same build artifacts (T340226) which then get a unique version taggs assigned to them
== Work in progress Spec ==== Research ==
- Use semver (Semantic Versioning) https://semver.org/The built artifacts consist of components from loads of different sources with different versioning strategies:
- Start with a major version of 2.0.0 (so this is bigger than current 1.39 mw version based releases)|Component|Explicit versioning|Communication of breaking changes|Link|Notes|
|---|---|---|---|---|
|MediaWiki|yes (e.g. 1.39.4), but not semver, going from 1.39 to 1.40 contains breaking changes (for the user?), so a minor MW version update would probably lead to a mayor wikibase suite version bump|yes, in changelog|[Changelog](https://gerrit.wikimedia.org/g/mediawiki/core/%2B/HEAD/HISTORY)|We might want to add unreleased security patches to our builds T341450|
|MediaWiki Docker image|no, version only represents the MW version built in, not the underlaying tools such as apache (from debian base image) or php (from php base image)|no|https://hub.docker.com/_/mediawiki/|Released by a volunteer https://github.com/wikimedia/mediawiki-docker https://phabricator.wikimedia.org/project/view/6633/, apparently looking for support T330367|
|PHP Docker image (base for official MediaWiki Docker image)|yes, but only PHP version, apparently does not get updated when the underlaying debian gets updates, as older php version images are only pushed a long time ago|yes, through PHP version|https://hub.docker.com/_/php| |
|Debian Docker image (base for official PHP Docker image)|yes, Debian versioning, but not semver, a datetime string getting updated on security patches|yes, with major release|https://hub.docker.com/_/debian| |
|Wikibase|no, ensures MW compatibility on REL branches|**TODO** RESEARCH| [Release notes](https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/refs/heads/master/RELEASE-NOTES-1.40) | should receive security patches as long as the related MW version is supported!? We might want to add unreleased security patches to our builds T341450 |
|other WMF hosted extensions, e.g. CirrusSearch|no, ensure MW compatibility on REL branches|**TODO** RESEARCH| [Extension Page](https://www.mediawiki.org/wiki/Extension:CirrusSearch) | should receive security patches as long as the related MW version is supported!? We might want to add unreleased security patches to our builds T341450 |
|other extensions from e.g. GitHub|arbitrary versioning strategies, sometimes just a main branch| | | |
|MariaDB Docker image|yes, following mariadb version|probably through mariadb version, **TODO** RESEARCH|https://hub.docker.com/_/mariadb|might need updates as soon as base libs get updates|
|WQS release|yes, 0.y.z|**TODO** RESEARCH| |we build it into an openjdk docker image which is needs updates as well, NB, the one we are using is deprecated and the tag we are using received the last update 4 years ago, so probably in 2019|
|WQS frontend|no, master branch|||built into an docker hub official nginx image, needs nginx and base system patches|
|QuickStatements|no, master branch||| based on php image, see above|
|MagnusTools|no, master branch|||used in the QuickStatements container|
|anything missing?| | | | |
== Suggestion - Request For Comments ==
- We use SemVer (Semantic Versioning) https://semver.org/
- Breaking changes increment major version e.g. 3.0.0
- Feature releases increment minor version, e.g. 2.1.0
- Fixes, e.g. security increment patch version, e.g. 2.0.1
- Start with a major version of 2.0.0 (so this is bigger than current 1.39 mw version based releases)
- We version the built artifacts, not the pipeline code
- The pipeline repo still might have tags to note which versions of wikibase can be built with a certain version of the pipelinecode has a rolling release main branch until we need something different
- We use tags on the pipeline main branch to note which version of pipeline main builds which release version
- A version f82a7cff of the main branch could have the following tags
- v2.1.0 the latest release of the old/lts version
- v3.0.0 the latest release of the current version
- v4.0.0-pre20230528 the latest build of the upcoming unreleased version (TODO: we cannot use the date, can we build without updating the build code?)
- All built artifacts of one version are together considered one wikibase suite release, that is:
- Container images for MediaWiki+WikiBase+Extensions aka Bundle, QueryService, etc
- docker-compose files defining the whole stack ready to run
- env files configuring the whole stack ready to run
- see T340234 for more information
- We might want to provide
- stable releases not including any breaking changes for the user
- support them "for a while" (as long as the respective MW version is supported?)
- there might be several supported stable releases in parallel, e.g. 2.x.x for mediawiki 1.39, and 3.x.x for mediawiki 1.40
- cutting edge builds in order to be ready to release the next stable as soon as upstream (mediawiki) becomes stable (T343692)
- The pipeline code at a certain commit only builds the latest of all supported versions of the artifacts, e.g. the pipeline main at commit fe234ac builds
- Wikibase Suite 2.3.1 (MW 1.39.3)
- Wikibase Suite 3.0.4 (MW 1.40.1)
- and Wikibase Suite 4.0.0-pre.X (unreleased MW 1.41)
- We could use docker image tags to deliver individual versions as well as stable branches
- Pushing the latest build of our artifacts as 3.0.4, 3.0 and 3 allows the users to pull a specific version as well as a stable "channel"
- Our distribution, the docker-compose file, might just reference the stable channel of images, e.g. "wikibase-bundle:3"
- How do we distribute different versions of our distribution? (T340234)
- Is this a git repo as well?
- Do we create a zip of it with docker compose referencing the correct image versions?
The built artifacts consist of components from loads of different sources with different versioning strategies:
|Component|Explicit versioning|Communication of breaking changes|Link|Notes|
|---|---|---|---|---|
|MediaWiki|yes (e.g. 1.39.4), but not semver, going from 1.39 to 1.40 contains breaking changes (for the user?), so a minor MW version update would probably lead to a mayor wikibase suite version bump|yes, in changelog|[Changelog](https://gerrit.wikimedia.org/g/mediawiki/core/%2B/HEAD/HISTORY)|We might want to add unreleased security patches to our builds T341450|
|MediaWiki Docker image|no, version only represents the MW version built in, not the underlaying tools such as apache (from debian base image) or php (from php base image)|no|https://hub.docker.com/_/mediawiki/|Released by a volunteer https://github.com/wikimedia/mediawiki-docker https://phabricator.wikimedia.org/project/view/6633/, apparently looking for support T330367|
|PHP Docker image (base for official MediaWiki Docker image)|yes, but only PHP version, apparently does not get updated when the underlaying debian gets updates, as older php version images are only pushed a long time ago|yes, through PHP version|https://hub.docker.com/_/php| |
|Debian Docker image (base for official PHP Docker image)|yes, Debian versioning, but not semver, a datetime string getting updated on security patches|yes, with major release|https://hub.docker.com/_/debian| |
|Wikibase|no, ensures MW compatibility on REL branches|**TODO** RESEARCH| [Release notes](https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/refs/heads/master/RELEASE-NOTES-1.40) | should receive security patches as long as the related MW version is supported!? We might want to add unreleased security patches to our builds T341450 |
|other WMF hosted extensions, e.g. CirrusSearch|no, ensure MW compatibility on REL branches|**TODO** RESEARCH| [Extension Page](https://www.mediawiki.org/wiki/Extension:CirrusSearch) | should receive security patches as long as the related MW version is supported!? We might want to add unreleased security patches to our builds T341450 |
|other extensions from e.g. GitHub|arbitrary versioning strategies, sometimes just a main branch| | | |
|MariaDB Docker image|yes, following mariadb version|probably through mariadb version, **TODO** RESEARCH|https://hub.docker.com/_/mariadb|might need updates as soon as base libs get updates|
|WQS release|yes, 0.y.z|**TODO** RESEARCH| |we build it into an openjdk docker image which is needs updates as well, NB, the one we are using is deprecated and the tag we are using received the last update 4 years ago, so probably in 2019|
|WQS frontend|no, master branch|||built into an docker hub official nginx image, needs nginx and base system patches|
|QuickStatements|no, master branch||| based on php image, see above|
|MagnusTools|no, master branch|||used in the QuickStatements container|
|anything missing?| | | | |
- All of the above can trigger a version bump
- Need to decide whether it is patch, minor or major
- **What is a breaking change? What is the interface our users rely on?**
Work in progress...