docs: add HeaderConfig to SecurityConfig + new Gudeline Proposals

[39zde]

I fixed some typos.
Also added documentation for merged PR #11485. Effective since 2.1.0

Edits:

Title

Updated title from add HeaderConfig to SecurityConfig to docs: add HeaderConfig to SecurityConfig + new Gudeline Proposals

Guideline Proposals

New Features / Version Display

Add guideline for displaying the version, a feature was introduced via new SinceVersion component

Badge Lifetimes

The sidebar has the ability to display badges next to an entry.
Add a guideline for how long a badge with the text contents of New is allowed to be displayed.

[netlify]

✅ Deploy Preview for tauri-v2 ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	9bd4f30
🔍 Latest deploy log	https://app.netlify.com/sites/tauri-v2/deploys/673514e729ed330008ca5467
😎 Deploy Preview	https://deploy-preview-2950--tauri-v2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 99 (🔴 down 1 from production) Accessibility: 100 (no change from production) Best Practices: 100 (no change from production) SEO: 100 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[FabianLars]

Goes into effect for next minor release (v2.1.0).

Hmm, i think something like a generic Since 2.1.0 header would be nice to have because i assume this will be a somewhat common occurence. cc @vasfvitor

[39zde]

Goes into effect for next minor release (v2.1.0).

Hmm, i think something like a generic Since 2.1.0 header would be nice to have because i assume this will be a somewhat common occurence. cc @vasfvitor

Changed it to Effective since 2.1.0

[vasfvitor]

Goes into effect for next minor release (v2.1.0).

Hmm, i think something like a generic Since 2.1.0 header would be nice to have because i assume this will be a somewhat common occurence. cc @vasfvitor

sorry I'm not sure I get it. Do you mean that we will be having more minors with new feats that needs to be noted as Effective since 2.x.y at the docs?

[FabianLars]

yes, exactly. for example in the v1 docs we often mention 1.3 for the first version with nsis support or 1.1 for tauri icon but only as part of the guide text, not via a seperate visual element.

[39zde]

This feature is included for the next minor release. This being 2.1.0. So it does not make sense to publish the documentation before that. So I changed the PR description from

Goes into effect for next minor release (v2.1.0).

to

Effective since 2.1.0

If I was meant to add a notice in the documentation itself, then it's a misunderstanding on my part.

@FabianLars mentioned "1.1 for tauri icon", which says in form of regular paragraph text:

Starting with @tauri-apps/cli / tauri-cli version 1.1 the icon subcommand is part of the main cli:

Would adding Effective since 2.1.0 somewhere in the guide text suffice or is This feature is part of tauri/tauri-utils since version 2.1.0 better?

[vasfvitor]

Effective since 2.1.0

this would be enough if on the top of the page detached from content, maybe a banner (if it isn't too much visually)

[39zde]

Since there definitely will be the need for other Since x.y.z notices, I propose the component SinceVersion, to have something consistent going forward.
The Comp would look like this:


and links to the related release page.

Also I couldn't find any guidelines, on the Badge New, on how it should be used and how long something is considered new.
For now I just said 6 Months in Contributing.md, but that's just a place holder. That's something, which requires multiple peoples input.

On the changes to Contributing.md I'm not quite set, so please voice your opinions.

[39zde]

To get formatting Workflow to pass, would mean breaking the page and making the code unpleasant to read. I wouldn't want to change the current formatting much, if possible.

Could be related to #2284, but I haven't looked into it.

[FabianLars]

no problem, just add the pages that prettier would break to the .prettierignore file

[39zde]

Also I couldn't find any guidelines, on the Badge New, on how it should be used and how long something is considered new.
For now I just said 6 Months in Contributing.md, but that's just a place holder. That's something, which requires multiple peoples input.

Say this guideline receives approval. How to enforce it?
I have a reminder set in my calendar, but that's not solution, I suppose.

So, have a file (eg. .github/Bage-Lifetimes.md) with the dates of when the badge should be removed?

# Removal Dates

List of files and dates, on which the `New` badge should be removed.
| Directive           | Description                                        |
| ------------------- | -------------------------------------------------- |
| Order               | Insert so, that the next removal is always on top. |
| Date Format         | `YYYY.MM.dd`                                       |

- [`http-headers.mdx`](../src/content/docs/security/http-headers.mdx): 2025.05.13

Or is there some CI workflow for notifications or something like a delayed commit. Both of these come with their own set problems and considerations.

[vasfvitor]

Or is there some CI workflow for notifications or something like a delayed commit. Both of these come with their own set problems and considerations.

well... for now I think this is enough. It's great. I'll open an issue and let it open while we figure it out. 6 months is ok imo.

is this pr ready?

[39zde]

is this pr ready?

I got nothing more to add. Green light from me.

[vasfvitor]

thanks, great work on everything!