Skip to content

Conversation

@marcustyphoon
Copy link

@marcustyphoon marcustyphoon commented Jul 9, 2025

Description

Last year, I started a project to see if New XKit could include all of its extension code in the XKit package, making all extension updates go through Mozilla/Google review, as required to stay listed on their stores. We merged #2148 into master as part of this (making various additional changes afterward), and made a "legacy" 7.9.2 branch with the code prior to that change that would service the currently-released 7.9.2 XKit version as it always has: by distributing extension updates to users directly through github. Due to a number of factors, namely issues with Mozilla extension review and various consequences resulting from that, it's clear that this is not a viable path forward.

This, therefore, restores the 7.9.2 branch's contents back to master, dropping the unreleased changes and shelving the idea for the foreseeable future (we can make a 7.10.0 branch to be the "shelf"). Thus, "New" XKit will continue to be disallowed on extension stores, as is appropriate given our stance that XKit Rewritten is the future of XKit and our recommendation that people use it. "New" XKit will also thus continue to have any changes that we make to it deployed rapidly with minimal hassle, in case we want to keep parts of it working for the userbase that still has it installed (which definitely exists; I regularly see posts with screenshots that prove this).

This codebase is the work of many and there's a ton of history in it. In that sense I want to show it some respect, and not leave its primary branch in a state of limbo. (To that end, I also have a cleanup of the build tooling to go along with this, which I'll put in another PR.)

Note: the first commit is generated with git checkout --no-overlay 7.9.2 -- ., so in a sense it's a machine-generated diff.

For comment: should we do this and should we do this this way? There are other methods (though I think force pushing 7.9.2 to the master branch would be a pretty terrible idea and that's the main relevant other method, to my knowledge, so... maybe there aren't really.)

Testing steps

The cleanest way to test this is probably to check it out to the "master" branch of a fork and make sure the CI and deployment actions work; I'll probably do so at some point and show the results in a comment below.

@marcustyphoon
Copy link
Author

marcustyphoon commented Jul 10, 2025

For testing purposes, I have created a new fork of this repository and merged this PR branch into master. The resulting actions runs are here: https://github.com/marcustyphoon-test-organization/XKit/actions / marcustyphoon-test-organization@7c87d6a / marcustyphoon-test-organization@c96dacc (note this is not in a sense an evergreen link; github iirc does not save old actions runs)

@marcustyphoon marcustyphoon requested a review from hobinjk July 10, 2025 23:04
Copy link

@hobinjk hobinjk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM, glad to see that the action runs continue to function seamlessly. The no-overlay-generated commit feels like a good solution. Linear history is more valuable than accurate git blames any day

@marcustyphoon
Copy link
Author

Note to self: if you want to keep the packaged/7.10.0 branch usable after pressing this button, you must manually copy all script changes that get merged into main into it.

@marcustyphoon marcustyphoon merged commit cf4e6fd into master Aug 3, 2025
1 check passed
@marcustyphoon marcustyphoon deleted the marcustyphoon/7.9.2-revert branch August 3, 2025 22:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants