The commit id 172cbd2e77e235e0eead6bb5022ad9185a45cafd is the web-v2025.2.2 tag. I have not yet merged the changeset for the v2025.2.2 branch vaultwarden/vw_web_builds#8 so this currently would still use the unpatched version.

edit: I've merged it, so it should be changed to vaultwarden/vw_web_builds@2974170

Yes, I was aware just wanted to point to the correct branch, not an external repository and for testing build even an unpatched one was enough.
Updated to vaultwarden/vw_web_builds@31e5dd1 which I believe is latest now.

Ah, yeah, "Rebase and merge" also changes the commit id.

@stefan0xC do you plan to update the v2025.3.1 branch ?

Edit:
A yes missed vaultwarden/vw_web_builds#14, if merged I can update the build script.

It has been merged.

Updated to vaultwarden/vw_web_builds@19f6dee

Yea, this seems like a good starting point for the short term.

I'm only missing a good way of working for the vw_web_builds.
Like, how do we keep in-sync with upstream.
Do we keep the main branch 1:1 in-sync with upstream
Should we create an own main branch, like vw_main which we link to a specific client tagged version?
And when a new version is released by Bitwarden, we sync that branch to a specific tag/hash and apply changes if needed?
And, then tag our custom versions upon the vw_main branch?

It might be best if we have a document on how to work on that so that we can't make a weird mistake (Which is always possible of course).

I have never maintained a fork with my own changes and try to keep upstream patches/changes in sync. So i have no real clue. I might have a general idea though.

I believe the current process used @stefan0xC is working well:

• Creating a new branch for each Bitwarden release.
• Rebasing the modifications on top of the tag.

With this process I believe preparing a new release is as simple as starting from the previous version and using an interactive rebase on top of the new tag to ensure to keep only the Vaultwarden modifications and fixing the conflicts.

This allows to easily keep track of each release and do not require to force push on a main branch.

Only suggestion I would add is later on to move the release code from this repository to the main branch of vw_web_builds.

This would allow to :

• Use only one repository / archive this one.
• The main branch would then have a reference to the latest release.

I' have skipped the separate PR step for my changeset and just pushed a new v2025.4.1 branch directly. If we adopt this PR we would still have to update the pointer to the branch we want to build, etc.

Oh, and I've just realized that I have forgotten to remove the bitwarden_license code from newer versions of the web-vault (ever since vaultwarden/vw_web_builds#2 has been merged). So this would have to be rectified in our fork as well because without the apply_patches.sh script those files will not be removed after checkout anymore.
edit: done vaultwarden/vw_web_builds@44d5a4b

web-v2025.4.2 was released maybe we could try to make the release using this PR ?

web-v2025.4.2 was released maybe we could try to make the release using this PR ?

Sounds good to me.

web-v2025.4.2 was released maybe we could try to make the release using this PR ?

I've added the changeset for v2025.4.2. cf. vaultwarden/vw_web_builds@b9151b7

Well, the CI Build seems to have passed and created a tar file.
So, that is nice.

I've updated the web-vault for the new v2025.5.0 and noticed that since web-2025.4.1 the create new organization screen throws an exception because this.taxComponent is not defined.

I've updated the branches to disable the sales tax accordingly:
vaultwarden/vw_web_builds@80c6b74 (v2025.4.2)
vaultwarden/vw_web_builds@93c4d42 (v2025.5.0)

Updated to point to v2025.5.0.