chore: Add wikibase-lts and deploy-lts products #813
Conversation
|
NX release does the right thing 🥳: 
|
|
A couple of notes after looking into things a bit more today:
|
|
|
||
| ### 🏡 Chore | ||
|
|
||
| - bump mediawiki to 1.42.3, bump extensions |
There was a problem hiding this comment.
| - bump mediawiki to 1.42.3, bump extensions | |
| - bump mediawiki to 1.39.10, bump extensions |
|
|
||
| - bump mediawiki to 1.42.3, bump extensions | ||
|
|
||
| ## (from **[email protected]** (2024-10-09)) |
There was a problem hiding this comment.
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 [email protected]
|
|
||
| ### 📖 Documentation | ||
|
|
||
| - Link to MediaWiki bundled extensions |
There was a problem hiding this comment.
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.
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:
The switch from "released from 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 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. |
|
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 ...for wikibase-lts to make the IMAGE_NAME wikibase |
I am not so sure. In my latest mental model, we only merge the LTS and non-LTS product on dockerhub. But in the NX/git world, they would be two products. Especially to have NX properly derive versions from git tags |
| @@ -71,9 +71,12 @@ else | |||
| ) | |||
| fi | |||
|
|
|||
| # transform TAGS to build args | |||
| IMAGE_NAME=$(jq -r '.name' package.json) | |||
There was a problem hiding this comment.
Could we also just change the name in package.json? Without any code change?
There was a problem hiding this comment.
No, I think this is not a good idea. I think we need to keep the -lts around until we finally publish to dockerhub only. Otherwise we need to change too many things, e.g. local image versioning vs latest only, how to identify images when pushed to/pulled from GHCR...
|
@rti following along with #815 👍🏼 I was digesting this all a bit more yesterday, and doing a little research on how nx themselves manage their own LTS version. They use minor version branches such as 19.3.x. The more I rewound to looking at our options, the more I flip again to thinking we would be best to just have an LTS branch. After digesting I realised that I had become convinced that LTS is in fact not a separate product, but simply as an earlier version of the Wikibase product. You helped me see that it is in fact only that, and that this will become evident sometime when LTS becomes 1.43 that our [email protected] releases are our LTS releases. It is looking to me now like the two directory version of things here is only solving one problem we encountered: However, I think what we're doing otherwise is actually again adding complexity where it needs not be there. I don't think it actually results in a simplified workflow for releases nor make anything possible that wasn't before with 2 branches. Here is what I think should be our priorities right now:
|
|
@lorenjohnson I am not convinced. I still like the approach to only have one branch and I think it does make things simpler. It is a bit of a compromise, but the alternative to maintain more branches also does not come without compromises. We had it for a while. I would really like to try the single branch approach now and learn from it. One part why the single branch, lts-product approach still has quite some appeal for me is how @RickiJay-WMDE put it: "This is a mono repo thing". It just makes sense how we set up the repo now. Branching the whole directory structure would be weird because we would have elasticsearch, quickstatements, all the tests, etc. in two branches, but they are actually always in sync. So this would be constant merging or cherry picking (as we had it). NX also gets hick ups, not only for version choosing but also for changelog generation, and depending on a patched version of nx could complicate things too. |
|
@lorenjohnson Tests for LTS and latest are passing over here in #815. Would love to hear what you think about the actual changeset. |
|
That's fine. I did a write-up of much more careful evaluation of each scenario yesterday, including the procedure for how the lts branch would be managed and then closed a browser window on accident and lost it 😢 So this second pass I didn't work that hard to make the case clear here, but I do think that we are basically making a new bit of complexity (tolerable in this case) due to simply not having made clear decisions and documentation on the 2 branch workflow. We were in sync when we decided to check out this 2 directory solution, and I was excited about it. I came to another perspective since and I'd like to come back and chat about it more until we arrive back at the same page again. I can be won back over, but I saw things in reflection that felt pretty clear and they are just hard to lay out here in comments readily. Yes, I will lave comments on your code too. |
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.
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).