change Billing Email -> Email

[tessus]

As per discussion: dani-garcia/vaultwarden#2849 (reply in thread)

[stefan0xC]

turns out there were also a few whitespace errors in the patch file, which my editor fixed.

if they were in the source files we may not be able to apply the patches. Have you tested this?

[tessus]

I now used make generate-patch

[stefan0xC]

Can you rename the file to patches/v2022.10.0.patch so your change between the two versions is easier to see? I don't think it's necessary to create a new patch file for this.

[stefan0xC]

I don't think there is a benefit of keeping the organization email displayed as Billing Email for our intended target audience ("individuals, families, and smaller organizations") since Vaultwarden does not implement the subscription plans or billing system anyway and the suggested change of just displaying Email is minimal and maintaining it should be easy.

[tessus]

Thanks for your comment. I am more than happy to take care of this in the future. Should this ever generate any issues, just ping me and tell me to fix this. ;-)

[BlackDex]

Can you rename the file to patches/v2022.10.0.patch so your change between the two versions is easier to see? I don't think it's necessary to create a new patch file for this.

Actually, it is better to have the later version here, so v2022.10.2, becuase we want to have some form of change chain. That this specific fix was not in the 2022.10.0 patch before.

We even create a v2022.10.2a for example when we make some other fixes, so that we at least know if someone is using the wrong vault.

[BlackDex]

I think this is fine, though not a must for me personally to have this changed.

[BlackDex]

Not sure if this will end-up into the current version. I might still want this to have the file changed to v2022.10.2 though.
But i think v2022.11.0 will be released any time soon.

[tessus]

Ok, but let me ask you this. Since v2022.10.2 is already released, should I not rename the file to v2022.10.2a? For me it doesn't matter, I just want to understand how and why.

@BlackDex Please let me know, I'll rename it right away:

• v2022.10.2.patch
• v2022.10.2a.patch

Edit: updated the version numbers.

[BlackDex]

Well, v2022.11.x is not released yet, so none of those :).
In theory it should be named v2022.10.2a, since indeed we already have a v2022.10.2 release.
Not sure how @dani-garcia looks at this, but there isn't a .10.2 patch, only a .10.0.

In theory that could mean a patch file named v2022.10.2 and a new tagged release called v2022.10.2a.
However, to be consistent, the patch file should then be called v2022.10.2a also. So, in the end i would go for that, that is more clear i think.

[tessus]

Oops, I updated the version numbers in my previous comment, but I don't think that gh sends another email for an edit.

Btw, you said that v2022.11.0 might be released soon. This would require at least dani-garcia/vaultwarden#2893 and dani-garcia/vaultwarden#2899 to be merged. However, right now there has not even been a 1.27.0 vw release (with the group support and other changes - current main).
I am trying to understand the release schedule and versioning. e.g. let's say v2022.11.0 comes out, but it will only work with the above 2 fixes in the server. A package maintainer would add this as a requirement, but can't know the version number that will include these 2 PRs in advance. Thus a roadmap or an idea how the versioning works could help a lot.

[tessus]

I can squash the 2 commits.

Some projects do not want a force push in a PR, since it will destroy the comment history. Please advise.

[BlackDex]

I can squash the 2 commits.

Some projects do not want a force push in a PR, since it will destroy the comment history. Please advise.

I think this is fine. It's not that there are 30 commits ;)

[dani-garcia]

Well, v2022.11.x is not released yet, so none of those :). In theory it should be named v2022.10.2a, since indeed we already have a v2022.10.2 release. Not sure how @dani-garcia looks at this, but there isn't a .10.2 patch, only a .10.0.

In theory that could mean a patch file named v2022.10.2 and a new tagged release called v2022.10.2a. However, to be consistent, the patch file should then be called v2022.10.2a also. So, in the end i would go for that, that is more clear i think.

The names of the patches are mostly informational, really, with our current build system it tries to match the vault version you're selecting against the patches and uses the latest one if there's no match, but in the docker builds we are using the commit hash, so it will always just select the latest one.