janbrasna / server-side-tls Goto Github PK

… and vice versa in some cases.

… if possible, to correct chronology +consistent version naming.

Release tags can then be edited to include the proper part of CHANGELOG +a link to URL for the .json spec maybe?

These release tags can then be linked from wiki under each version in history, providing more details +permalink to .json version, version by version.

Change the order in paragraphs linking to the currentmost symlink, and if needed showing how to link to an exact version — changing the wording "as an example", without the need to bump the version every single time the specs update.

Future possible improvement is a link to every single version .json from the version history (or linking to github release page with a link there possibly…)

Since conf tool is moved elsewhere, there's no need to build any new github-pages here. That gives us chance to start cleaning up a new default branch, say master or main, based on the gh-pages, but then going disjunct ways (default can purge legacy links that won't get (un)published anywhere; while gh-pages can contain legacy redirects and historic json specs working…), to make it crystal clear this repo now houses only current wiki pages, no legacy technicalities that can stay frozen in place out of sight…

1. gh-pages will be kept for legacy purposes, to build redirects et al. to the now-unused deployment to github-pages +to keep all original links to raw/blob/tree files intact as these have gh-pages branch name baked in…
2. new master can be made more accurate reflecting what's the repo content these days, with no legacy content present just to make old urls working.
3. this enables the cleanup of master as all the subfolders +icons etc. can be gone now — as master is for updates to *.mediawiki only; and on the other hand the gh-pages branch can have the *.mediawiki files removed so they stop being deployed to github-pages where they don't most likely belong.

OQ:

• are *.mediawiki files published to github-pages for a reason? how they get to the wiki? manually? or via the github-page url somehow? i. e. if their gotoprod path is not via the gh-page, than this could be pruned to strictly separate uptodate content from legacy shims.
• are the aws/bucket assets for ….tls.sec….mozilla.org pulled automatically or manually? i. e. if nobody publishes them, they stay at the current version? if there are any build scripts, those point to gh-pages branch? then we can have default/master with uptodate content without caring about the legacy deployments as well.

Repo settings for the home sidebar —›

• About: change wording from TLS tools to hosting the wiki pages
• URL: link to wiki page instead of the config tool

README:

1. state this is for wiki +issues with the recommendations
2. config tool has its own repo now +issues w/ configs should go there
3. somehow mention json definitions, the legacy files here are only not to break links so JSONs (+their issues(?) should be open in the config tool repo too(?))