chore: Add wikibase-lts and deploy-lts products

[lorenjohnson]

Moves our Wikibase and Deploy LTS products beside our main releases of these products all in one repo. This reduces complexity, and solves a number of problems. The work in this branch completes much of what is needed to take this path, with the following remaining to be decided/addressed.

• Decide if we really want to just tag lts-x.y.z on Dockerhub or use wikibase-lts as a new image (doesn't require any release configuration change)
• Update testing setup such the tests run on both LTS products as well as latest product releases.
  • Stretch goal: Run tests on both versions only when changes to the LTS products are detected, perhaps utilising nx affected.

Note: This branch includes a the yet unreleased Wikibase LTS 1.0.1 (MediaWiki 1.39.10 patch release), and the related Deploy LTS 1.0.1 releases already prepared including CHANGELOG updates (review those to see the format used).

[lorenjohnson]

NX release does the right thing 🥳:

[lorenjohnson]

A couple of notes after looking into things a bit more today:

• After a bit of poking I have a pretty clear idea of how to amend the test setup to work well with this setup and only run LTS tests when there are changes in the LTS releases from the last release.

• To highlight the perhaps obvious, if we were go this direction we can at any time inspect the diff between build/wikibase and build/wikibase-lts (to see what we might want or need to back port) by running git diff --no-index build/wikibase-lts build/wikibase, or a little more recklessly simply copying the contents of build/wikibase over build/wikibase-lts then do a git diff. Same for deploy and deploy-its of course. Git is our friend.

[rti]

Suggested change

	- bump mediawiki to 1.42.3, bump extensions
	- bump mediawiki to 1.39.10, bump extensions

[rti]

I am unsure whether we really want to include this information. Going forward, NX wouldn't generate it either. I think I would prefer just the list of changes since wikibase-lts@1.0.0

[rti]

Just to spell it out once here: So whenever we change something on the wikibase product in the future, we always have to consider bringing it to lts too, right when we implement the change, review and merge it. In case we decide the change goes to latest and lts, we would apply the same change to both directories in the same PR, so NX would generate the same changelog entry for any of the both products whenever we release the next version.

I like this.

[rti]

Decide if we really want to just tag lts-x.y.z on Dockerhub or use wikibase-lts as a new image (doesn't require any release configuration change)

I am still sympathizing with the idea to make wikibase and wikibase-lts one product on dockerhub. This is how the process could look like:

• Currently we maintain Wikibase 3.0.2 and Wikibase 1.0.0
• With this approach
  • Wikibase 3.0.2 (Mediawiki 1.42) would live in the build/wikibase directory as the wikibase "nx project", tagged with wikibase@3.0.2 git tags
  • Wikibase 1.0.0 (Mediawiki 1.39 - LTS) would live in the build/wikibase-lts directory as the wikibase-lts "nx project", tagged with wikibase-lts@1.0.0 git tags
  • Patching Wikibase 3 would happen in the build/wikibase directory and eventually lead to a release git tagged with wikibase@3.0.3
  • Patching Wikibase 1 would happen in the build/wikibase-lts directory and lead to a release git tagged with wikibase-lts@1.0.1
  • Now What happens when we release a wikibase based on 1.43? (anytime from now)
    • Mediawiki 1.39 is still supported, so we probably should support it too, so Wikibase 1 will continue to receive patches in the wikibase-lts directory
    • Mediawiki 1.43 will be released with Wikibase 4 from the wikibase directory.
    • Note that Mediawiki 1.43 is a LTS version...
  • Now What happens when we release a wikibase based on 1.44? (some time in summer)
    • Mediawiki 1.44 will be released with Wikibase 5 from the wikibase directory.
    • Mediawiki 1.43 was an LTS version, so we can build our LTS version based on that too
    • We could copy the 1.43 based build/wikibase directory to build/wikibase-lts and continue maintaining it there, continuing with version number 4, as wikibase-lts@4.x.x

The switch from "released from build/wikibase" to "released from build/wikibase-lts" could be opaque to the user if we push from both "nx projects" to the same "dockerhub project" maintaining a consistent versioning throughout the full product lifecycle.

So users could onboard to Wikibase 4 now as soon as we release it and keep using it for years as long as we keep it in lts support. That we change the build folder name over time would not be relevant for the user.

I do agree though, that we need some special handling for the wikibase-lts git tag then. I wondered if we could have a new workflow triggered by wikibase-lts@X.Y.Z git tags. This workflow could just tag wikibase@X.Y.Z and push it to the repo to trigger the original publish workflow. Is this a hack or clever design? ;)

This is raw thoughts dumped here, I might be missing something, or even a whole lot. The purpose of this comment is to further fuel the discussion.

[lorenjohnson]

After more discussion the conclusion for now is to keep the wikibase naming for the product for both git tags and docker hub releases. This requires maybe only adding an exception here:

wikibase-release-pipeline/build/build.sh

Line 75 in 1f8648f

IMAGE_NAME=$(jq -r '.name' package.json)

...for wikibase-lts to make the IMAGE_NAME wikibase