Page MenuHomeFreeBSD

Find outdated versions of FreeBSD in the documentations
AbandonedPublic

Authored by bofh on Apr 17 2023, 3:27 AM.
Tags
None
Referenced Files
Unknown Object (File)
Apr 27 2024, 6:51 AM
Unknown Object (File)
Apr 27 2024, 6:50 AM
Unknown Object (File)
Apr 27 2024, 6:50 AM
Unknown Object (File)
Apr 27 2024, 4:29 AM
Unknown Object (File)
Dec 23 2023, 1:21 AM
Unknown Object (File)
Nov 29 2023, 9:41 PM
Unknown Object (File)
Aug 16 2023, 11:26 PM
Unknown Object (File)
Jul 4 2023, 7:37 AM
Subscribers
None

Details

Summary

This patch adds a vale rule to find the outdated versions of FreeBSD in the documentation section. This is not meant to run within the website section as our website needs to mention or refer to the older versions of FreeBSD

Diff Detail

Repository
R9 FreeBSD doc repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

bofh requested review of this revision.Apr 17 2023, 3:27 AM
bofh created this revision.

This section of the Porter's handbook also needs to refer to old versions: https://docs.freebsd.org/en/books/porters-handbook/versions/.

I have also found a FreeBSD security advisory example in the handbook with references to old versions: https://docs.freebsd.org/en/books/handbook/book/#_format_of_a_security_advisory . Unless someone wants to always use latest examples, you might try to play with scopes to work around it.

Another old version referenced as an example can be found here: https://docs.freebsd.org/en/articles/explaining-bsd/#_bsd_releases .

I suggest to run the rule on the whole documentation to which it should apply and see how many false positives it gives and how many can be fixed.

This section of the Porter's handbook also needs to refer to old versions: https://docs.freebsd.org/en/books/porters-handbook/versions/.

I have also found a FreeBSD security advisory example in the handbook with references to old versions: https://docs.freebsd.org/en/books/handbook/book/#_format_of_a_security_advisory . Unless someone wants to always use latest examples, you might try to play with scopes to work around it.

Another old version referenced as an example can be found here: https://docs.freebsd.org/en/articles/explaining-bsd/#_bsd_releases .

I suggest to run the rule on the whole documentation to which it should apply and see how many false positives it gives and how many can be fixed.

Just FYI you can actually skip an instance of a vale generated error/warning/suggestion by putting this just above the line causing the problem:

pass:[<!-- vale FreeBSD.__RULE_NAME__ = NO -->]

Thanks, this is a useful information, I will remember it.

Some of the previous regex were a bit error prone. So fixed those ones.

This section of the Porter's handbook also needs to refer to old versions: https://docs.freebsd.org/en/books/porters-handbook/versions/.

For this page I would really advice on skipping this ruleset. I am working on how the pass thing workout with hugo and asciidoctor.

I have also found a FreeBSD security advisory example in the handbook with references to old versions: https://docs.freebsd.org/en/books/handbook/book/#_format_of_a_security_advisory . Unless someone wants to always use latest examples, you might try to play with scopes to work around it.

I just stumbled upon something in this example. There is a term 8.4-STABLE which is totally incorrect. We don't have a STABLE with dot releases only with Major Versions. I will submit another review for this.

Another old version referenced as an example can be found here: https://docs.freebsd.org/en/articles/explaining-bsd/#_bsd_releases .

Again I stumbled upon 5-CURRENT. Maybe we should come up with a macro which will automatically set it to our latest CURRENT.

In D39612#904547, @bofh wrote:

… We don't have a STABLE with dot releases …

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262494 yesterday's comment requests addition of 13.2-STABLE to a menu in Bugzilla, and so on.

https://www.freebsd.org/where/#_freebsd_13_2_stable

Looks like the sound to noise ratio is too high to utilize this rule. So I am abandoning this.

For what it's worth, I would find a rule such as this useful without the rule being comprehensive, or perfect …